RE: Versioning and HTML

Ian Hickson [mailto:ian@hixie.ch] wrote:
>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.

Umm, no, it wouldn't; I said:

>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.

Unless I missed something, none of the HTML5 features have moved past CR.  We could have a conversation about DOM storage if you like, but we're talking about implementing features that are not past CR - and I agree with RO'C on the mail you sent, except that I'm suggesting that "accepted in the spec" is likely "past CR" unless a browser is willing to say they won't whip out the "compatibility" card (as Apple is doing with SQL store now, AIUI).

>> 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.

Buy-in is kind of irrelevant; buy-in is not a standard or a full spec that you won't have to change.  I'd say instead that

>> 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.

That's incorrect, in my opinion, because it presumes that you are a replacement for CR.

>> >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.

Here, at least, I think we agree.  But prefixing such things would make it clearer that they're not "standard" until moved past CR.

-Chris

Received on Monday, 27 April 2009 19:12:07 UTC