« Return to Thread: update ISSUE-41
Re: ISSUE-41 versioning comments
by Doug Schepers-3
::
Rate this Message:
Hi, Folks-
Outside of the context of the conversation, I found this summary to be a
little jumbled. This is not a criticism; I know this email was a
largely unstructured work in progress, and summarizing a multi-person,
multi-topic async thread is a Sisyphean task.
For readers that weren't there, it might help to know that the summary
actually contains several voices, and dialog and debate.
I have a few clarifications for the parts I was involved in, mostly
pertaining to SVG and the idea of platform consistency and
interoperability. Replies inline with clipped passages...
Larry Masinter wrote (on 6/18/09 8:28 PM):
>
> We don't want to open the door to vendors shipping
> proprietary extensions and worrying about the consequences later. Think
> about how the OpenSVG effort is using the language. (?)
I'm not sure what "OpenSVG" is referring to.
FWIW, I'm all for experimental extensions of languages as a means for
rapid prototyping and feedback (implementer, author, and user). The SVG
WG has recently discussed creating a single "experimental SVG"
namespace, for just such a purpose; this would be a vendor-neutral
temporary placeholder, similar to but distinct from the vendor-specific
"-vendor-" prefixes in CSS, which unfortunately persist past the point
where they should be adopted as an official part of the language or
dropped for consideration. We are interested in exploring this idea
further, but have not made any conclusions yet.
Another related approach the SVG WG is doing is script prototyping of
features. I used this in a recent spec, the SVG Parameters spec and
primer, and it dramatically changed the way in which I designed the
language feature and how it was perceived by people who read the spec,
clarifying many aspects.
http://www.w3.org/TR/SVGParam/
http://www.w3.org/TR/SVGParamPrimer/
> Discussion about<SVG> and other features;
>
> Claim: for the Open Web platform to work, there should be feature
> parity across browsers... if it can be done by a plugin, great, but
> this isn't a theoretical exercise, this is a matter of pragmatics.
>
> Does this mean no browser can ever implement any feature that some
> other browser doesn't implement, and otherwise the Open Web platform
> cannot work?
>
> But how many browsers count? The Amazon Kindle doesn't implement all
> the browser features that Mozilla and Chrome implement, so does the
> Aamazon Kindle hinder the platform? If Microsoft implements something
> other browsers don't, does that hinder the platform?
>
> If MS drops important features, it does hinder it... authors can't
> rely on their content working on it (assuming enough people are using
> the kindle as a browsing device).
This was a question around how important feature parity is to a
successful platform (where a platform is roughly a design/development
toolchain and the corresponding deployment and runtime environment); I
was clarifying that it was not good enough that a feature (in this case,
SVG) be "allowed", but rather that it should be "mandated", because
otherwise the authors, users, and authoring tool vendors suffer; the
most direct example is my assertion that IE should support SVG or the
platform suffers.
Larry followed up on my claim by asking if the Kindle should be
considered as hindering the "Open Web"/HTML5 platform if it doesn't
support a particular feature. I replied, "if it drops important
features, it does hinder it... authors can't rely on their content
working on it (assuming enough people are using the kindle as a browsing
device)". [1] (So, his restatement here captures the essence of the
argument, but the transition was a little lossy and confusing,
conflating MS IE and the Kindle... the whole discussion did make sense
at the time, I swear.)
> the idea that<canvas> is fast and<Svg> isn't -- is that really true?
> And are those intrinsic issues with<svg> or just the accident of how
> much effort has gone into optimizing the<canvas> implementations?
>
> it's unreasonable to believe that all desirable web graphics can be
> supported by canvas. certainly Google Earth or Lively couldn't be. So
> there has to be some choice about which use cases are important to
> build in and which ones aren't, and what it means to "mandate" a
> feature.
>
> What's the extensibility story: it harms the platform if 3 out of 4
> browsers decide they want it, and the 4th holds out?
Yes, that's my claim.
Actually, to be more precise, it's better to think of the situation as
independent installations of browsers, and totally ignore the vendor
aspect (for a moment).
Let me lay out a thought experiment: ignore the vendor/brand aspect, and
suppose that the situation is simply a matter of independent
installations of browsers, and that adding features to (or "upgrading")
individual installations is based not on a bundled set of features, but
merely the individual costs of upgrading (time, energy, hassle,
bandwidth, financial cost, risk of upgrade problems, risk of untrusted
extensions, etc.); in other words, any combination of features is
roughly as likely as any other combination.
Let's say there are 1 billion browser installations; if a feature works
on 1 million of those, then it's unlikely to succeed, no matter how
crucial those 1 million people think it is; authors can't use it if they
want to write content that they don't know to be constrained to those 1
million installations, and have to rely on a fallback or a different
feature, so less compelling content will be created. When you start
getting up to 300 million or so, the case changes: there is more freedom
to use the feature, more compelling content, and greater chance for a
"tipping point", where most or all installations are upgraded with that
feature, because the value to the user is such that they will
individually be more likely to encounter content, at least once, that is
perceived to be compelling enough to upgrade. A couple of factors that
effect this adoption rate are the ease with which the feature is
installed, and the perceived trustworthiness of the source of the
feature. This is sort of the "free-market" model of feature adoption.
Of course, this is *not* how it works. In the current browser market,
this adoption is hindered by another, more strict constraint: which
features are bundled together into an individual browser. Because it is
monumentally difficult to overcome the momentum of the clear and simple
upgrade path from one version of a particular browser to the subsequent
version, the browser with the largest starting market share is going to
strictly constrain uptake of features that are not supplied as part of
that browser.
To me, the goal of standards should be to aid the content creators and
end users of the service (in this case, the Web), which is a social
goal; I understand that some standards bodies are organized instead
around the principle of primarily benefiting the vendors involved, but I
hope that I do not work for such a standards body. Naturally, vendors
should and do benefit from meeting the social goal, and competition for
market share is part of that benefit, but that motive should not change
the nature of the social goal; it should be complementary or orthogonal
to it.
> Mozilla proposes animation extensions to PNG, writes a specification,
> implements it; someone at Opera thinks it's a good idea and implements
> it too.
>
> Is it that 2 out of 4: minority, 3 out of 4, majority?
Part of that depends on market share. Firefox has substantial market
share, so if FF and one other browser support something, I think giving
it serious consideration for standardization is advisable. If all major
browsers except one support a feature (in this case, SVG), then for
consistency and interoperability, it should be mandated that all
browsers provide support, if they want to claim to support the HTML5
platform. If they choose to compete on some other factor than claims to
support HTML5, then they can do whatever they want, but they shouldn't
be allowed can't have it both ways, because it fractures the market and
hurts the users of the platform.
> With APNG, the format is designed to degrade (to a single static
> image) in browsers that don't support it, so the idea is people will
> start using it with the static fallback in IE (and most WebKit-based
> browsers)
>
> If it gets sufficiently widely used then the other browser developers
> will decide it's worth implementing.
I'm not quite so free-market... by analogy, recent economics have shown
us that this kind of "deregulation" is not good for a society.
> But is there's a clear boundary between things-like-APNG and
> things-like-SVG ?
>
> SVG might be the best exemplar we have at hand, since it is supported
> in all the major desktop browsers save IE... it's a perfect case to
> serve as an example for consideration.
>
> They're different, but i don't know how to draw the line. Why mandate
> SVG but don't mandate APNG? Is the the distinction non-technical, but
> rather how many browsers implement it? ?
Standards are not all about technical considerations, but about
logistics as well. In the case of W3C in particular, there is also the
social good to be considered. So, the number of existing
implementations is certainly a factor, logistically, because it makes
the goal of interoperability more easily achieved.
On a technical note, SVG is different than APNG in that it is not a
black box; APNG is a matter of supporting a codec, while SVG integrates
more closely with HTML, CSS, and Javascript.
FWIW, I think APNG should probably also be mandated. The technical cost
of doing so is minimal, since there are open-source implementations that
could be used.
> But what about MathML? it's of limited use so you woudn't mandate it?
MathML is a special case. Though it's not supported natively by any
browser in full (FF and Opera both have simple implementations), it does
meets a social need that leads me to believe that it should also be
mandated as part of the HTML5 platform.
[1] http://krijnhoetmer.nl/irc-logs/html-wg/20090618#l-296
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Outside of the context of the conversation, I found this summary to be a
little jumbled. This is not a criticism; I know this email was a
largely unstructured work in progress, and summarizing a multi-person,
multi-topic async thread is a Sisyphean task.
For readers that weren't there, it might help to know that the summary
actually contains several voices, and dialog and debate.
I have a few clarifications for the parts I was involved in, mostly
pertaining to SVG and the idea of platform consistency and
interoperability. Replies inline with clipped passages...
Larry Masinter wrote (on 6/18/09 8:28 PM):
>
> We don't want to open the door to vendors shipping
> proprietary extensions and worrying about the consequences later. Think
> about how the OpenSVG effort is using the language. (?)
I'm not sure what "OpenSVG" is referring to.
FWIW, I'm all for experimental extensions of languages as a means for
rapid prototyping and feedback (implementer, author, and user). The SVG
WG has recently discussed creating a single "experimental SVG"
namespace, for just such a purpose; this would be a vendor-neutral
temporary placeholder, similar to but distinct from the vendor-specific
"-vendor-" prefixes in CSS, which unfortunately persist past the point
where they should be adopted as an official part of the language or
dropped for consideration. We are interested in exploring this idea
further, but have not made any conclusions yet.
Another related approach the SVG WG is doing is script prototyping of
features. I used this in a recent spec, the SVG Parameters spec and
primer, and it dramatically changed the way in which I designed the
language feature and how it was perceived by people who read the spec,
clarifying many aspects.
http://www.w3.org/TR/SVGParam/
http://www.w3.org/TR/SVGParamPrimer/
> Discussion about<SVG> and other features;
>
> Claim: for the Open Web platform to work, there should be feature
> parity across browsers... if it can be done by a plugin, great, but
> this isn't a theoretical exercise, this is a matter of pragmatics.
>
> Does this mean no browser can ever implement any feature that some
> other browser doesn't implement, and otherwise the Open Web platform
> cannot work?
>
> But how many browsers count? The Amazon Kindle doesn't implement all
> the browser features that Mozilla and Chrome implement, so does the
> Aamazon Kindle hinder the platform? If Microsoft implements something
> other browsers don't, does that hinder the platform?
>
> If MS drops important features, it does hinder it... authors can't
> rely on their content working on it (assuming enough people are using
> the kindle as a browsing device).
This was a question around how important feature parity is to a
successful platform (where a platform is roughly a design/development
toolchain and the corresponding deployment and runtime environment); I
was clarifying that it was not good enough that a feature (in this case,
SVG) be "allowed", but rather that it should be "mandated", because
otherwise the authors, users, and authoring tool vendors suffer; the
most direct example is my assertion that IE should support SVG or the
platform suffers.
Larry followed up on my claim by asking if the Kindle should be
considered as hindering the "Open Web"/HTML5 platform if it doesn't
support a particular feature. I replied, "if it drops important
features, it does hinder it... authors can't rely on their content
working on it (assuming enough people are using the kindle as a browsing
device)". [1] (So, his restatement here captures the essence of the
argument, but the transition was a little lossy and confusing,
conflating MS IE and the Kindle... the whole discussion did make sense
at the time, I swear.)
> the idea that<canvas> is fast and<Svg> isn't -- is that really true?
> And are those intrinsic issues with<svg> or just the accident of how
> much effort has gone into optimizing the<canvas> implementations?
>
> it's unreasonable to believe that all desirable web graphics can be
> supported by canvas. certainly Google Earth or Lively couldn't be. So
> there has to be some choice about which use cases are important to
> build in and which ones aren't, and what it means to "mandate" a
> feature.
>
> What's the extensibility story: it harms the platform if 3 out of 4
> browsers decide they want it, and the 4th holds out?
Yes, that's my claim.
Actually, to be more precise, it's better to think of the situation as
independent installations of browsers, and totally ignore the vendor
aspect (for a moment).
Let me lay out a thought experiment: ignore the vendor/brand aspect, and
suppose that the situation is simply a matter of independent
installations of browsers, and that adding features to (or "upgrading")
individual installations is based not on a bundled set of features, but
merely the individual costs of upgrading (time, energy, hassle,
bandwidth, financial cost, risk of upgrade problems, risk of untrusted
extensions, etc.); in other words, any combination of features is
roughly as likely as any other combination.
Let's say there are 1 billion browser installations; if a feature works
on 1 million of those, then it's unlikely to succeed, no matter how
crucial those 1 million people think it is; authors can't use it if they
want to write content that they don't know to be constrained to those 1
million installations, and have to rely on a fallback or a different
feature, so less compelling content will be created. When you start
getting up to 300 million or so, the case changes: there is more freedom
to use the feature, more compelling content, and greater chance for a
"tipping point", where most or all installations are upgraded with that
feature, because the value to the user is such that they will
individually be more likely to encounter content, at least once, that is
perceived to be compelling enough to upgrade. A couple of factors that
effect this adoption rate are the ease with which the feature is
installed, and the perceived trustworthiness of the source of the
feature. This is sort of the "free-market" model of feature adoption.
Of course, this is *not* how it works. In the current browser market,
this adoption is hindered by another, more strict constraint: which
features are bundled together into an individual browser. Because it is
monumentally difficult to overcome the momentum of the clear and simple
upgrade path from one version of a particular browser to the subsequent
version, the browser with the largest starting market share is going to
strictly constrain uptake of features that are not supplied as part of
that browser.
To me, the goal of standards should be to aid the content creators and
end users of the service (in this case, the Web), which is a social
goal; I understand that some standards bodies are organized instead
around the principle of primarily benefiting the vendors involved, but I
hope that I do not work for such a standards body. Naturally, vendors
should and do benefit from meeting the social goal, and competition for
market share is part of that benefit, but that motive should not change
the nature of the social goal; it should be complementary or orthogonal
to it.
> Mozilla proposes animation extensions to PNG, writes a specification,
> implements it; someone at Opera thinks it's a good idea and implements
> it too.
>
> Is it that 2 out of 4: minority, 3 out of 4, majority?
Part of that depends on market share. Firefox has substantial market
share, so if FF and one other browser support something, I think giving
it serious consideration for standardization is advisable. If all major
browsers except one support a feature (in this case, SVG), then for
consistency and interoperability, it should be mandated that all
browsers provide support, if they want to claim to support the HTML5
platform. If they choose to compete on some other factor than claims to
support HTML5, then they can do whatever they want, but they shouldn't
be allowed can't have it both ways, because it fractures the market and
hurts the users of the platform.
> With APNG, the format is designed to degrade (to a single static
> image) in browsers that don't support it, so the idea is people will
> start using it with the static fallback in IE (and most WebKit-based
> browsers)
>
> If it gets sufficiently widely used then the other browser developers
> will decide it's worth implementing.
I'm not quite so free-market... by analogy, recent economics have shown
us that this kind of "deregulation" is not good for a society.
> But is there's a clear boundary between things-like-APNG and
> things-like-SVG ?
>
> SVG might be the best exemplar we have at hand, since it is supported
> in all the major desktop browsers save IE... it's a perfect case to
> serve as an example for consideration.
>
> They're different, but i don't know how to draw the line. Why mandate
> SVG but don't mandate APNG? Is the the distinction non-technical, but
> rather how many browsers implement it? ?
Standards are not all about technical considerations, but about
logistics as well. In the case of W3C in particular, there is also the
social good to be considered. So, the number of existing
implementations is certainly a factor, logistically, because it makes
the goal of interoperability more easily achieved.
On a technical note, SVG is different than APNG in that it is not a
black box; APNG is a matter of supporting a codec, while SVG integrates
more closely with HTML, CSS, and Javascript.
FWIW, I think APNG should probably also be mandated. The technical cost
of doing so is minimal, since there are open-source implementations that
could be used.
> But what about MathML? it's of limited use so you woudn't mandate it?
MathML is a special case. Though it's not supported natively by any
browser in full (FF and Opera both have simple implementations), it does
meets a social need that leads me to believe that it should also be
mandated as part of the HTML5 platform.
[1] http://krijnhoetmer.nl/irc-logs/html-wg/20090618#l-296
Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
« Return to Thread: update ISSUE-41
| Free embeddable forum powered by Nabble | Forum Help |
