RE: Versioning and html[5]

Ian Hickson [ian@hixie.ch] wrote:
>I'm going to focus on my proposed alternative to versioning instead of
>focusing on the negative aspects that versioning would introduce since I
>can't see how to convince you of the negative aspects (you seem to be
>understanding what I'm saying, just not reaching the same conclusions).

Indeed.  I have a different perspective.  I've acquired that perspective by shipping IE repeatedly over the last eleven years, and working through the ways we've broken customers in the process.  You don't seem to empathize with the negative aspects of breaking customers.

>> 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?)
>
>The current spec is not finished, correct. I would hope that when it is
>finished it is strictly compatible with legacy content that works in IE7
>(as a superset in some areas and probably a subset in others -- e.g. I
>would't plan on describing HTML+Time or the binary-level APIs of ActiveX,
>and at the same time, we do plan on adding new features).

OK.  If you don't describe HTML+TIME, then you're not strictly compatible with what IE7 supports today.  This is not an argument to support HTML+TIME; but we can't shut it off.  Neither do I want to maintain it as-is.

>> I would love to implement the spec as written.  Give me versions to hang
>> proper implementation on over time--
>
>You misunderstand. I mean, if you implement the spec without versioning
>and find something breaks the Web, then we should change the spec. To know
>when something breaks the Web, you have to tell us. To tell us, you have
>to know. To know, you have to implement it without versioning. Then,
>*before* you ship with that change, we fix the spec and you fix the
>implementation so that the spec and the implementation are both compatible
>with legacy content. Thus, you can implement the spec, without versioning,
>and not break any legacy content.

We cannot "fix the implementation" after we've shipped it once.  Nearly any change other than fixing crashing bugs causes backward compatibility problems for us.  That's why in IE7, we hid basically everything but crashing fixes behind the quirks mode switch.

>> 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.
>
>Yes, and this is a bad thing. We want to get away from this. If we can
>make a spec that means that browsers can implement the Web's technologies
>identically, then we don't need browser-sniffing.

We will never implement precisely the same set of features and bugs across all browsers.  Even across all major browsers.  Reality of competition intrudes.  We just won't - there will be no steady state of the web, and no end goal of the platform.  It's a great goal to provide a common platform, and I really do support it and am working to make it happen in IE despite what you think - but imagining that we're going to someday reach nirvana there, rather than successively approximate a common platform, is naïve. It will be better than it is today, but it will never be true that anything that runs on IE will run on Safari (even "anything in the standard").

-Chris

Received on Friday, 13 April 2007 17:21:37 UTC