RE: Versioning and html[5]

Ian Hickson [mailto:ian@hixie.ch] wrote:
>By "compatible" I don't mean "an exact description of". And I'm not
>interested in being compatible with IE7, I'm interested in being
>compatible with the content that assumes IE7. There's a big difference.

Indeed.  I understand your goal of the HTML5 spec being "mostly identically compatible with IE."  I don't disagree with it.  It just doesn't match what IE needs to support for backward compatibility.  That's not incompatible, and I'm not asking you to change the tenets under which you've been operating.

I'm telling you one thing, and asking another (only slightly related).

Telling: IE will have opt-in compliance to the standards over the next few releases.  We must do this in order not to break our customers and the web.  This is not something I'm looking for the HTML WG to condone or codify in a spec.

Asking: Please don't think that because you want every version of HTML after HTML5 to be completely backward compatible with HTML5 that you should just drop a version number altogether.  Hedge your bets, consider it insurance, and say <!DOCTYPE html PUBLIC "html5">.  It triggers standards mode in all major UAs.  Personally, I expect an HTML6 to say "html6" - I think it helps UAs and authoring systems.  You don't - okay.  It's really not a big deal right now.  But in HTML6, when it turns out we forgot to normatively specify some behavior in IE5, and Firefox and IE do it differently, we're not going to break that behavior - meaning knowing that we're looking at HTML6 will be a good thing.

>> > 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.
>
>Please reread the paragraph I wrote. I clearly stated that these would be
>changes *before* shipping.

Your mail falsely presumed that we can "try it out without versioning," and we'll know somehow (beta testing?) what we break.  Our experience with IE7 proved that such is simply not the case.

>> 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.
>
>I understand this so far. I don't think it's the right thing to do, but
>that's not the point. I understand that you think it is right and why you
>think it is right.

Good.  That's the first time you've said that.  I don't expect you to agree.

>> 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).
>
>I don't understand why you think steps 1 and 2 have any bearing on the
>version of the HTML spec. Imagine if we weren't doing HTML5 -- surely
>you'd still have to do versionning, right? Are you suggesting that in the
>entire time before HTML5 is finished (at least a decade or more --
>consider that HTML4 still hasn't reached the level of interoperability
>that we are aiming for with HTML5, so we know that it will take at least a
>decade), you will only freeze bugs once?

I don't believe HTML5 will take a decade to start being deployed.  It's not when the standard gets turned into a Recommendation that matters to compatibility, it's when the content starts being deployed.

>What would you do if you need a new opt-in switch before HTML6 is started?

Add one.  But when people started deploying HTML6, I'd want it to be automatically opted in.

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

We're currently on a path of "spec feature, get implementation experience,
fix spec to match implementation experience, iterate", which as far as I
can tell is the same thing (though not necessarily only with IE).

Yes, I am suggesting that.

>> You could start, then, by not ripping out the pieces we rely on, like
>> classid and codebase.
>
>This is a fallacy, as discussed here:
>
>   http://lists.w3.org/Archives/Public/public-html/2007Apr/0632.html

No, I disagree with you.  ActiveX can be implemented on other platforms (I believe Mac IE5 had an implementation), and embed is the moral equivalent anyway (I note the explicit reference in HTML5 to the Netscape Plug-in model - nice!).  codebase I believe we do misuse - it's a URI, but not as stated - but classid I don't think we do, we just invented a URL type of "classid:" for it.

>> >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.
>
>You think it's a mistake to make the spec be such that implementing the
>spec is all that is needed to handle existing content?

I don't think it's possible to have ONE spec that specifies how to handle ALL content on the web today.  Some requires IE.  Some requires Firefox.  In this case, you need to choose.  Yeah, normally I'd go for the 80% behavior of matching IE - but if it's wacky, keep the right spec and help prioritize that as an issue to change (under opt-in, and then under new DOCTYPEs) for IE.

>That is, you think that browsers actually *should* have to implement
>something that is incompatible with the spec in order to render legacy
>content?

Yeah, pretty much.  See above - some of the web is written to IE bugs, some isn't.  How can you support both?  Document authors use a plethora of techniques to determine which UA is being used (including the time-honored technique of "not caring").

>If this is really what you think, what do you think the point of the spec
>is? Just a guide or influence?

Hmm.  Guide?  Determination of how to do it right, that we all converge on?

>> I'm happy to have competition in the browser space.
>
>You are proposing a path that will lead to it being nearly impossible to
>compete in this space, very similar to the path that has led to it being
>nearly impossible to compete in the word processing space.

Wow, I simply disagree with that statement.  So does your employer, as they have a competing word processor to Microsoft Word.

>> 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.
>
>Authors want consistency across implementations more than they want an
>ideal spec that isn't implemented anywhere.

I'd think we could give them a third option - an ideal spec that all implementations converge on.

-Chris

Received on Sunday, 15 April 2007 00:24:45 UTC