RE: Versioning and html[5]

Ian Hickson [mailto:ian@hixie.ch] wrote:
>On Thu, 12 Apr 2007, Chris Wilson wrote:
>> versioning will still tell you that your browser isn't new enough to
>> handle, say, that 3d canvas element that gets added in html6.
>
>I don't understand this. Could you elaborate with an example?

We're running on the presumption that everyone will always have the latest browser.  That's not true.  It would be useful for IE to be able to identify, for example, that we are unlikely to be able to handle canvas content.

>> However, having versioning in HTML will allow us to eradicate the need
>> for authors to put this switch in every single document to opt in to
>> good behavior, because we'll know that HTML6 content/apps won't expect
>> to have the bugs we ship IE.next with.
>
>You are suggesting tying a browser-specific set of bugs to a specification
>on a different release cycle. I'm even more against doing that than I am
>against the idea of freezing bugs in the first place. You're free to
>support whatever switches you believe you need in your browser (even if it
>means that it'll be intentionally perpetually non-compliant), but the W3C
>should not condone this or even remotely legitimise it.

Hmm.  No, I'm saying ("we" means Microsoft in this list):
        1) for compatibility reasons, we will have to freeze bugs in place in default behavior.
        2) because I want to move the implemented platform forward, of course we will fix bugs and add features - but they will have to be under an opt-in switch.
        3) Whenever a new HTML version is "shipped," we can automatically say for that version, we'll mask out all our old crappy behavior (that you used to have to put an opt-in in every document to avoid).  IE's behavior for HTML of that version will represent our best, most-standard compliant behavior for HTML, because we know we don't need to bugward-compatible.

>If you want the W3C spec to have a version switch, then the spec must
>define how browsers must act *in all the versions that the switch
>supports*. That means that if you want a switch (or the lack of a switch)
>to imply that IE7 behaviour must happen, *we absolutely must specify
>exactly what IE7 does* so that other browsers can implement it too.

That sounds like you want to be on the "suggest features to IE and then document what they implement path," then.  (No, I'm not suggesting that path.  I'm pointing out that you claim that's your goal, but you really want to make it happen by forcing IE on your path too - and for compatibility reasons, we simply can't do that, and in some places (like ActiveX) we don't think it's a good idea.)

>Maybe it would help, however, if instead of assuming that compliance to
>HTML5 will mean broken pages, we worked on the assumption that
>implementing HTML5 correctly will mean all pages work. That's what the
>other browser vendors want, it's what the WHATWG set out to do three years
>ago and has been doing ever since, it's what authors want.

You could start, then, by not ripping out the pieces we rely on, like classid and codebase.  "All pages" include pages that exist today that are designed for IE, and explicitly, to us, it includes pages that rely on IE-isms like ActiveX, scrollbar-color, and HTML+TIME (which is a profile of SMIL, BTW, it's not some random proprietary thing we invented).

>Where HTML5 does break pages, we need to fix the spec. If this means
>getElementById() changes to look for 'name' attributes, sobeit.

I think that's a mistake, but okay.

>Sometimes
>it may be that IE's behaviour *can* change because few enough pages depend
>on some edge case that it's ok to change it.

I'm saying the default answer to that question is no.  We have a different set of constraints.

>Sometimes changes in IE's
>behaviour will, in beta tests, show to be utterly impractical, and then we
>can use this feedback to fix the spec. In the end, all browsers benefit
>from the experience, we improve competition in the browser space, and the
>authors and users benefit.

I'm happy to have competition in the browser space.  I'm even suggesting we get on a long term path where it's easier.  I am not agreeing to breaking our customers in order to stimulate competition in the browser space.  If you want to do this, I'm happy to provide resources to help you investigate why IE does anything that it does, so that you can write a spec that matches precisely that.  I'm not really convinced that's the best basis for an HTML specification that will stand the test of time - it seems like you're working toward a world where instead of just swearing at IE's wackiness, web developers will swear at the wackiness of the spec and everyone's implementation.

>Assuming from the start that we can never achieve interoperability is
>defeatist in the extreme and compromises the entire point of standards.

I believe any application CAN be interoperable.  I do not believe that EVERY POSSIBLE application written based on some arbitrarily-defined set of standards (and there is no definition of such a set today) WILL automatically work across all possible UAs, and that's not even addressing the ActiveX/plugin issue.  (Even if you assume embed, you don't know if they'll actually have Flash 4.)

I'd like to enable web developers spend as near as zero time as possible fixing browser interoperability problems.  I don't think we can obviate the need for production web applications to test on multiple browsers if they want their apps to work cross-browser conclusively.

-Chris

Received on Friday, 13 April 2007 19:01:35 UTC