[whatwg] HTML6 Doctype

Sat Aug 28 21:09:47 PDT 2010

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 Castello

On Sat, Aug 28, 2010 at 8:15 PM, David John Burrowes
<bainong at davidjohnburrowes.com> wrote:
> 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
>
>