Re: Versioning and html[5]

Ian Hickson wrote:
> On Thu, 12 Apr 2007, Chris Wilson wrote:
>   
>> I agree with your premise (don't break the web) but not your conclusion 
>> (that spec-version information is therefore unnecessary).  Spec 
>> versioning will still tell you that your browser isn't new enough to 
>> handle, say, that 3d canvas element that gets added in html6.
>>     
>
> I don't understand this. Could you elaborate with an example?
>
>
>   
>> However, having versioning in HTML will allow us to eradicate the need 
>> for authors to put this switch in every single document to opt in to 
>> good behavior, because we'll know that HTML6 content/apps won't expect 
>> to have the bugs we ship IE.next with.
>>     
>
> You are suggesting tying a browser-specific set of bugs to a specification 
> on a different release cycle. I'm even more against doing that than I am 
> against the idea of freezing bugs in the first place. You're free to 
> support whatever switches you believe you need in your browser (even if it 
> means that it'll be intentionally perpetually non-compliant), but the W3C 
> should not condone this or even remotely legitimise it.
>
> If you want the W3C spec to have a version switch, then the spec must 
> define how browsers must act *in all the versions that the switch 
> supports*. That means that if you want a switch (or the lack of a switch) 
> to imply that IE7 behaviour must happen, *we absolutely must specify 
> exactly what IE7 does* so that other browsers can implement it too.
>
> Maybe it would help, however, if instead of assuming that compliance to 
> HTML5 will mean broken pages, we worked on the assumption that 
> implementing HTML5 correctly will mean all pages work. That's what the 
> other browser vendors want, it's what the WHATWG set out to do three years 
> ago and has been doing ever since, it's what authors want.
>
> Where HTML5 does break pages, we need to fix the spec. If this means 
> getElementById() changes to look for 'name' attributes, sobeit. Sometimes 
> it may be that IE's behaviour *can* change because few enough pages depend 
> on some edge case that it's ok to change it. Sometimes changes in IE's 
> behaviour will, in beta tests, show to be utterly impractical, and then we 
> can use this feedback to fix the spec. In the end, all browsers benefit 
> from the experience, we improve competition in the browser space, and the 
> authors and users benefit.
>
> Assuming from the start that we can never achieve interoperability is 
> defeatist in the extreme and compromises the entire point of standards.
>
>   
+1

Bruce