Re: ISSUE-41 versioning comments

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

Received on Friday, 19 June 2009 04:04:09 UTC