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

Re: Versioning and html[5]

From: Ian Hickson <ian@hixie.ch>
Date: Thu, 12 Apr 2007 20:51:55 +0000 (UTC)
To: Chris Wilson <Chris.Wilson@microsoft.com>
Cc: "public-html@w3.org" <public-html@w3.org>
Message-ID: <Pine.LNX.4.62.0704122023130.13484@dhalsim.dreamhost.com>

On Thu, 12 Apr 2007, Chris Wilson wrote:
> We can't afford to break what is currently working, so we will have to 
> provide opt-ins for web authors to say "hey, I know what I'm talking 
> about as of now, please give me standards compliant behavior," because 
> we know from experience that all but a very small number of authors 
> expect that in their content.

What you're actually talking about offering isn't "standards compliant 
behavior", but a frozen set of bugs for a particular browser version.

Basically you're saying that at certain release intervals, you want to be 
able to offer a new set of rendering behaviour. You're saying that after a 
certain amount of time, you intend to stop fixing bugs, and simply cut a 
new version. Right?

This mode isn't related to HTML releases, or to CSS releases, or WebAPI 
DOM releases -- it's related to _IE_ releases. If you want a versioning 
flag in your browser, you should provide an IE versioning flag, not an 
HTML one. It's quite possible than in the next 15 years it takes us to 
make HTML5 a REC, you'll have released 10 browser versions with 10 
different rendering engines. The HTML5 DOCTYPE doesn't affect that at all, 
since you'll presumably be wanting to stop breaking the new Web content 
with each release.

If this is indeed the case, then you shouldn't be asking for a change to 
the spec. Just add another IE comment syntax:

   <!--[ie 8]-->

...which makes IE browsers render the page according to the given IE 
version (and if there's no IE version flag, default to IE7).

As is *still happening today* with quirks mode, other browsers will be 
forced to implement the quirks in order to be compatible with the content 
that was intended to IE. Introducing a new version freeze every few years 
will increase the complexity of building a browser by orders of magnitude. 
In a few decades, it will be so prohibitively complex to write a Web 
browser rendering engine, and the browser that introduced each version 
will have such a ridiculously big advantage, that the market will stagnate 
and a single vendor will control its development. This may not be your 
intent today, but it would be the result. Exactly this has already 
happened with Office document formats, it's a repeating pattern.

It will increase the complexity of authoring by an order of magnitude too. 
Authors will become locked in to particular IE version numbers, unable to 
upgrade their content for fear of it breaking. Imagine in 17 years -- only 
twice the current lifetime of the Web! -- content authors will not have to 
learn HTML, they'll have to learn 4, 5, maybe 10 different versions of 
HTML, DOM, CSS, and JS, just to be able to maintain the various different 
pages that people have written.

This is one of the worst possible things Microsoft could do to the Web, 
and will in due course be one of the worst possible things Microsoft could 
do to itself. It is, in my opinion, irresponsible and downright anti- 

The alternative is to write the spec in such a way that implementing it 
does not cause significant breakage. Given that I want to write a spec 
that describes how to render the content in _all_ of IE's modes -- quirks, 
today's standards, tomorrow's standards -- such that an implementation of 
this spec can render the Web, I will have to do this regardless of whether 
Microsoft has the motivation to ensure the spec has no breakage or not. It 
would be much easier to do if you guys would simply say when you couldn't 
implement the spec as written.

Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Thursday, 12 April 2007 20:52:19 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:44:08 UTC