[whatwg] HTML6 Doctype

Sun Aug 29 08:33:37 PDT 2010

On 2010/8/28, at 下午8:52, Scott González wrote:

> What percentage of all versions of all browsers do you think fully
> support any version of any spec? Saying that browser X supports some
> part of CSS2 is no more or less useful than saying browser X supports
> some part of CSS as it is defined today (which is backward compatible
> with how it was defined on any previous day). Browsers are constantly
> adding new features and fixing bugs. We're also seeing much more
> frequent releases of browsers (and hopefully more frequent updates to
> "stable" HTML). Trying to map a version of HTML to a browser version
> isn't very practical. I'm not sure what kind of long, painful support
> issues you think would arise from not having a version number.

Hello Scott,

I agree that in the current situation, the clarity about what browsers support what degree of one of the specs isn't always very well defined.  There are zillions of charts out there on the web where people are trying to address that.  To me, the fact that those charts need to exist is a sign of a problem.

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, and that's really useful in situations where I'm targeting (either for development or support) the non-current version.  So, I have some trouble understanding why it is good to put (what I hope will be) a lot of innovation in just the HTML spec into one undifferentiated definition. (and, presumably similar stories for the other standards specs)

In any case, Ian did write that there was massive pressure to ensure that there is no versioning here.  That puzzles me, and I wish I understood it more.  But, maybe your answer is akin to their answer: the world's survived so far with little in the way of functional versioning, it'll continue surviving that way.  

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.

david

> 
> 
> On Saturday, August 28, 2010, 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
>> 
>> 