RE: Versioning and html[5]

Ian Hickson [mailto:ian@hixie.ch] wrote:
>What you're actually talking about offering isn't "standards compliant
>behavior", but a frozen set of bugs for a particular browser version.

Okay.  You're looking at one side of the coin and not the other - the one that is clearly marked "break behavior to follow the standard when author says that's what they want".

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

Not a certain amount of time.  When the potential disruption caused by our changes rises to a certain level, we will have to put those changes under an opt-in switch, just like quirks mode.  Potential disruption = (scope of change) x (adoption of current best mode).  I would hope that doesn't happen often.  We've certainly passed that threshold with (scope of how far IE doesn't follow standard)x(adoption of standards mode) today.

(As examples: high potential for our overflow changes in IE7, lower potential for adding quotes to <q>, near-zero potential for crashing bugs (side effects of algorithm change only))

>This mode isn't related to HTML releases, or to CSS releases, or WebAPI
>DOM releases -- it's related to _IE_ releases.

Yup.

>If you want a versioning
>flag in your browser, you should provide an IE versioning flag, not an
>HTML one.

Yup, and we will.  But our default mode for HTML4.01 will be quirks/standards mode as they are today.  If the HTML has a version that tells us it's more modern than that, we can opt in automatically.

>It's quite possible than in the next 15 years it takes us to

Yeeeek.

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

That's a pathological example of what I'm talking about.  I would think (scope)x(adoption) would not rise above our bar 10 times in 15 years.  If we even managed to release 10 versions in 15 years, I doubt very much that they would have significant web breakages in each one.  Do you really think it's going to take 15 years to get HTML5 signed off on as a Rec?  I'm already under the impression that you don't want substantive changes to parts of it.

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

Only if those new browsers are trying to copy IE bugs in our implementation of standards compliance.  You haven't all done that today.  (Overflow, hasLayout, etc.)

Look, you're trying to get content either be written to standards (which I think is awesome, and our tools are helping encourage), or you're trying to get us to force content to be "alive" - if it's written to IE, IE may change as we torque you to whatever the current standard is, or we fix some nasty bug that you didn't realize we had but depended on.  Sorry, we are not going to beat our own users and developers with that stick.  Our tools generate standards-compliant content today, not IE-specific content.  If they don't, let me know and I can hook you up with the appropriate tools guys to get that fixed.  That is certainly their goal.

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

You're making this sound like a solved problem.  If IE changes its behavior radically, it just breaks the web for everyone that is using IE.

>Exactly this has already
>happened with Office document formats, it's a repeating pattern.

Sorry, I'm not registering how you're using Office formats as an example.  Office formats are now thoroughly documented, with an open standard describing them.  Is that not progress?  (And please don't anyone start a debate about the OOXML process vs. the web.  I understand it is not the same as the development of HTML.)

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

Instead, you are suggesting that every author, web site owner and user will quake in fear every time Microsoft inflicts a new browser with potentially-breaking behavior on the world.  No thank you.  Enough people hate me already.

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

You are blowing this far out of proportion, Ian.  These are not different languages.  I'm trying to make it so that over time, without continually yanking every user, developer and web site owner's chain every time we release a new browser, we can have a clean specification that IE follows, along with every other browser that chooses to follow the spec.  We're not there today with a spec we all agree on.  Unless you bite off ActiveX, you won't ever get there.  You want a replacement that solves that issue (e.g.: <video> instead of embedding Flash classid <object>)?  Okay, I'm trying to work with you to get there.  I'm not going to inflict the horror of continuous behavior changes in IE on the world.

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

I don't understand how you get from "Not screwing our users" to "anti-competitive".  I am not trying to prevent other browsers from implementing exactly what IE supports today - if you want to, go for it.  If you want to write the spec to mirror precisely what IE does today, I'm okay with that too.  That is NOT what you have currently done with HTML5, nor is it the stated intent.  Unless David was serious that the WG should be suggesting features to IE and then documenting how we implement them.

>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

Ian, the spec you have today does not describe IE's platform.  Do you disagree with this statement (think carefully - no classid?  Flash doesn't work? Tons of "good idea" apis that we don't have?)

>would be much easier to do if you guys would simply say when you couldn't
>implement the spec as written.

I would love to implement the spec as written.  Give me versions to hang proper implementation on over time, and I'll even do it without an IE-specific opt in.  The fact of the matter is that today, web developers already serve different content to IE and Firefox.

-Chris

Received on Thursday, 12 April 2007 23:17:30 UTC