RE: Versioning and HTML

On Mon, 27 Apr 2009, Chris Wilson wrote:
> Ian Hickson [mailto:ian@hixie.ch] wrote:
> >On Fri, 24 Apr 2009, Chris Wilson wrote:
> >> The only way out of this would be for EVERY browser to very carefully
> >> only ship "proprietary-marked" (a la CSS' vendor extensions) versions of
> >> APIs/elements until the standard moves OUT of CR, and then add support
> >> for the standard naming and deprecate their proprietary-marked versions
> >> over time.
> >
> >Or at least, to do so with features that don't have obvious ways to be
> >updated without needing version syntax. Why is that a problem?
> 
> I didn't say it was - but aside from CSS, that's not what is happening.

This would be a more convincing argument if Microsoft hadn't agreed to 
renaming some of its APIs in IE8 and then forgotten to do so:

   http://lists.w3.org/Archives/Public/public-html-comments/2008Jun/0020.html

...despite being reminded to do so half a dozen times, and despite other 
vendors apparently understanding the convention without trouble:

   http://lists.w3.org/Archives/Public/public-html/2008Jun/0294.html

Microsoft could change its behavior, and then it _would_ be happening.


> Actually, there is the problem that web developers would have to 
> abstract their code to point to the mostly-interoperable implementations 
> of a feature, until that feature moved out of CR - you shouldn't use 
> <canvas> today, then, you should use <webkit-canvas>, <moz-canvas>, etc.  

This is why for features like new elements, vendors should always first 
get buy-in from the working group.


> We've had this question internally - e.g. for rounded border corners, 
> should IE bother doing -ms-border-radius, or just skip straight to 
> border-radius?

You use a prefix until it's stable -- meaning in CR, for CSS specs. With 
HTML5 I've been annotating the spec on a per-section basis to give 
implementors fine-grained detail on what is stable and what is not, and 
have been resonding to requests for advice from all browser vendors on 
this very matter.


> >In the case of the spec changing while there is already an 
> >implementation, it's not like the spec is going to have BOTH versions 
> >defined, and it's not like other browsers are going to want to impement 
> >BOTH versions.
> 
> It sort of depends what third-party applications are built on that 
> browser-specific implementation, I expect.  Sort of like if GMail is 
> built on Safari's SQL store support, and the spec changes to abstract 
> that more.  What should the spec do, in this case?

If other browser vendors believe they need to implement the feature, then 
it should be a first-class feature and specified, even if there are other 
features added that make it less important.

If other browser vendors believe that the feature isn't required to 
support Web content, then the spec can die and the feature can just be a 
transitory browser-specific feature.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Monday, 27 April 2009 18:54:28 UTC