W3C home > Mailing lists > Public > whatwg@whatwg.org > August 2010

[whatwg] HTML6 Doctype

From: Scott González <scott.gonzalez@gmail.com>
Date: Sat, 28 Aug 2010 23:52:21 -0400
Message-ID: <AANLkTi=qpjqPe1h8DG07MYErsgVH6jKR-h_XVfGjVKmZ@mail.gmail.com>
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.


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
>
>
Received on Saturday, 28 August 2010 20:52:21 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:09:00 UTC