Re: Versioning and html[5]

On 2007 April 12th Ian Hickson wrote:

> 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.

This sounds to be what IE will be doing, though it's explained here in a
way which isn't specific to IE and which suggests codifying the release
of other browsers being used is also useful:

  http://www.alistapart.com/articles/beyonddoctype

Also it happens to use an HTTP header (or <meta> equivalent) as its
hook, but it's along similar lines to the parsable comments suggestion:

> 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).

Here's an example:

  <meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4" />

That gives the impression that specifying FF=3 is a useful thing to do,
that some future release of Firefox will render pages differently based
on its presence -- something which hopefully will not be the case.

It's also unclear what a user-agent that isn't any of the 3 named there
(such as one written from scratch) should do on encountering the above
declaration.  Presumably it should try to emulate the behaviour of IE8
and Firefox 3, even though those behaviours aren't specced anywhere?

As Ian pointed out, that's likely to be a significant barrier to entry
for an attempted new web browser:

> 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-competitive.
> 
> 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.

Co-published with the above introduction to X-UA-Compatible, Eric Meyer
discusses pointential objections to it, though he doesn't cover the one
Ian raises above:

  http://www.alistapart.com/articles/fromswitchestotargets

Cheers.

Smylers

Received on Tuesday, 22 January 2008 11:52:02 UTC