W3C home > Mailing lists > Public > public-html@w3.org > April 2007

RE: Version information

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Sun, 8 Apr 2007 18:42:45 -0700
To: Brad Fults <bfults@neatbox.com>
CC: Alfonso Martínez de Lizarrondo <amla70@gmail.com>, Maciej Stachowiak <mjs@apple.com>, Anne van Kesteren <annevk@opera.com>, "L. David Baron" <dbaron@dbaron.org>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <5C276AFCCD083E4F94BD5C2DA883F05A27D6D61A56@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com>

bfults@gmail.com [mailto:bfults@gmail.com] wrote:
>Chris: Did you read Ian's reply? Your concerns were explicitly
>addressed in a reasonable fashion and the argument for a lack of
>versioning was put forth again, with startling clarity.

Yes, I did, and I disagree with it.  (Clearly, I left my chair hat in the office.)

>On 4/6/07, Ian Hickson <ian@hixie.ch> wrote:
>> They'll only have to implement the latest one. That's the whole point --
>> by strictly ensuring that all versions of HTML are, when designed,
>> backwards-compatible with all prior content, any browser that implements
>> HTML n+1 will automatically support any real content written for HTML n,
>> for all values of n.

And I don't believe you will actually make it 100.000% backward-compatible.  If we succeed (by, as I said, never deprecating or changing anything at all), or a UA doesn't care about that level of detail, then an additional version number won't hurt you.  If we mess up at that, or want to deprecate or change behavior but we didn't put in a version number, we're hosed.

I'm also being realistic - we will not get standards 100% right.  (Neither will anyone else, I would guess.)  Because being backward-compatible is a tenet for us, we will have to require authors to opt in to correct behavior.  New version numbers will automatically be opted in.

>> Look at it this way: today, how does a browser know what version of HTML
>> to implement? They always implement HTML4, because if you implement HTML4
>> you are automatically compatible with HTML 3.2 content, HTML2 content, and
>> so forth.
>>
>> Now, today this is complicated by a few factors:
>>
>>  * The XHTML1 language *isn't* backwards compatible with HTML4, so
>>    browsers have to implement both (or not do XHTML). The WHATWG specs
>>    go out of their way to define both HTML5 and XHTML5 as compatible
>>    languages with minimal differences required to handle legacy content.

Indeed.  The XML syntax of XHTML (any version) has failed thus far because 80+% of browsers don't directly support it, though, not because of the semantic language failing.

>>  * The quirks mode vs standards mode (vs almost standards mode, in the
>>    browsers that correctly implement the CSS inline box model) means that
>>    for HTML4, browsers need to have three slightly different
>>    implementations. The differences are relatively contained, however, and
>>    this is independent of the HTML version number. HTML5 again goes out of
>>    its way to limit the number of differences here (most are in CSS),
>>    though there's still some work we can do (e.g. in handling of </br>).

Actually, quirks mode is based on a version number.  Old versions of HTML (e.g. 3.2) get old behavior.  And again, the point is that you're changing with HTML5 - are you really positive you won't want to change again with HTML6?

>> > This is definitely a benefit of version information within the markup.
>> > In the future when someone comes across a document with HTML they know
>> > exactly which specification they need to implement.
>>
>> If we do our job right, they'll only have to implement *one* version, the
>> latest one, and it'll handle all content. In my opinion, the alternative,
>> namely that they have to implement several dozen versions to handle
>> content from several dozen years, is simply unworkable and unacceptable.

It simply isn't realistic to think that this will be the last version of HTML that will ever change behavior or deprecate anything, in my opinion.
Received on Monday, 9 April 2007 01:42:50 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC