[whatwg] HTML6 Doctype

[Ian Hickson]

On Sat, 28 Aug 2010, David John Burrowes wrote:
> 
> 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.

Non-versioned HTML is the only type of HTML we've had so far, in practice 
(the version numbers in older drafts of HTML have never had an effect). 
It's worked for 20 years, why would we change?


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

Except that that's never true. There has never been a browser, ever, that 
has supported all of one level of CSS and none of the next level. Same 
with HTML, the DOM, 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 :-).

http://caniuse.com/ actually solves this problem. Spec version numbers 
(whether in documents or just in the spec) do not.


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

You'll never find a useful test suite that coincides exactly with a 
version of a browser (almost by definition -- a test suite that finds no 
bugs is almost certainly either incomplete or covers a very narrow scope).


On Sun, 29 Aug 2010, David John Burrowes wrote:
> 
> As I see it, if I'm developing for other major platforms (java, osx, 
> windows, ...) I have a fair degree of certainty which versions of those 
> platforms support what features

Sure, because those are single-vendor solutions where the vendor's 
definition of the platform's version coincides exactly with the vendor's 
software with the same version.

A better parallel is something like C++, where you don't have certainty 
that the compiler from a particular vendor implementing a particular 
version of C++ will match the C++ spec exactly, nor that it will match the 
implementation of another vendor's implementation of the same version, 
insofar as feature support is concerned (i.e. I'm not just talking about 
bugs, but about how much of the spec is implemented).


> On 2010/8/28, at 下午9:09, Jonathan Castello wrote:
> > 
> > I would guess that new features would go in their own spec, like Web 
> > Workers, WebSockets, and so on. If that is the case, you can still say 
> > browser X supports things by naming the specs, e.g. Chrome supports 
> > WebSockets.
> 
> Jonathan, that is certainly true (about the multiple specs).  But I 
> think the original question (and, at least, my response to that 
> question) was speaking of just the html spec, and revisions of it, 
> itself.

Think about how HTML has been developed in the past 7 years. We've had 
only one version number. The world has survived fine. Why bother with that 
version number? It doesn't get us anything useful.

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