Hello all,

I wanted to chime in on this discussion.  Let me say up front that clearly the 
w3c and the browser vendors all are on the same page as you, Ian.  I'm not in 
the position to be challenging your collective wisdom!

But, I share some of the same concerns (and more) as David Bruant, and would 
like to understand why this non-versioned HTML is a good thing.  I keep 
imagining long, painful support issues.

>>>> What will this doctype be since it cannot be <!DOCTYPE HTML>?
>>> 
>>> It can be that. HTML is backwards-compatible, meaning that an 
>>> implementation of the spec in 2020 will handle content written to the 
>>> spec in 2010 correctly.
>> 
>> Even if I agree on this goal, I think that this is a very ambitious 
>> statement. From a formal point of view, how can you prove that a change 
>> that you make on a spec is backward-compatible with *any* content 
>> written following the 2010 spec?
> 
> We can't prove it, but we've never needed versioning for previous versions 
> of HTML, and there's massive pressure to ensure we continue to not use 
> versioning (the few experiments with versioning -- quirks mode and XHTML 
> -- have been found to be rather disappointing, to put it mildly).

> A number of other languages don't have versioning, for example CSS, C++.


I agree that they don't have access to versioning info from within the 
languages. 

But, CSS has some sense of versions (CSS, CSS2, and CSS3).  This gives me some 
ability to say "ah, SurfBrowser 1.0 and 2.0 supported CSS1, but with 3.0 they 
supported some of CSS2 etc etc.

That is, as long as I'm using the current browser, I know I've got support for 
whatever is latest.  But, when I'm providing support for folks using 
non-current browsers, there's some value in being able to estimate what will 
and won't work there. Saying "well, I have no idea if our app will work in the 
browser you have, because no one knows what form of the HTML spec it supported" 
doesn't go over very well with someone paying you money :-).  

Maybe it would make more sense to version the test suite in some fashion?  Then 
one could say: "SurfBrowser 7.8 passes the HTML test suite of March 15th, 2012" 
and so as long as folks know what that test suite is validating, then this 
might address support issues just fine.

david

Reply via email to