RE: Versioning and html[5]

Simon Pieters [mailto:zcorpan@gmail.com] wrote:
>I don't think anyone in this WG expects any browser vendor to break the
>Web. If implementing some part of the spec breaks the Web, then that is a
>bug in the spec, and should be changed so that it doesn't break the Web.

Actually, I think David Baron suggested exactly that, in what I quoted.  Given Microsoft's definition of "break the web," of course.

>> So, that sucks.  I don't want every other browser (and every browser to
>> come) to have to implement IE's bugs.
>> [...]
>> I also don't want to bake IE's poor behavior in some cases into the
>> standard -
>
>If today's content rely on them, then why not?

As I said, I'm okay with that path if that's what others want, but I don't think implementing exactly IE's behavior (including DOM) is their goal.  Some IE-specific stuff that's become popular, sure.  But not everything.  And we can't change, in content that is not identified as "new", the fact that getElementByID picks up 'name' attributes too, or whatever.

>> that would mean EVERYONE should have the hasLayout() side effects,
>
>Does hasLayout have side effects that would affect the HTML spec?

Possible bad example.

>> choose not to quote <q>, etc.
>
>I would be fine with that, FWIW.

Heh.

> [...] I'm frankly somewhat ambivalent about how much IE-ism we take into
> the standard, because it won't be exactly IE7's behavior, and therefore
> can't replace our current behavior when faced with text/html - because
> we can't Break the Web.

>If the defined behavior would be as close as IE7 as possible while still
>not tampering with other specs (in particular DOM and CSS), and wouldn't
>break the Web (to the extent possible), then what is the problem? (If
>implementing DOM or CSS would break the Web, then issue the WebAPI or the
>CSS WG, respectively.)

We (HTML WG) own DOM too.  And "as close to IE7 as possible" is different for IE (which can be EXACTLY IE7) than it is for Opera, Safari, FF, or any other non-IE-based browser, I imagine.

>> However, you need to understand that you can't ask the market leader
>> (and given some of my private conversations, even other UAs) to change
>> the details of what they're shipping today, without causing immense and
>> unnecessary pain to their users and developers.
>
>It may be necessary anyway should you want to conform to other specs, such
>as DOM and CSS. (If you don't care about conforming to other specs, like
>other browser vendors do AIUI, then I understand why you wouldn't want to
>change your behavior, but I don't understand why you would want to
>conform to this spec while not conforming to others. In any case,
>implementing HTML5 should make you more conformant to DOM at the same
>time.)

We will never be CSS2.1 compliant without some opt-in (or potentially the user forcing IE into "always standards" mode, which is really just a tester's/developer's feature).  We'd break compatibility in serious ways, UNLESS we know that the content post-dates our changes to IE.

>I think the intent is that a browser implementing the spec would work with
>the "real web" (which means IE bugs are specced, many are already in
>WHATWG's HTML5 proposal). Again, if that's not the case, it's a bug in the
>spec.

I'm fine with spec'ing any IE bug into HTML5 you want.  But I don't think that the desire of the WHATWG contingent is really, as David said, “[to] just become the committee to propose new features to IE's developers and then re-document them according to the bugs in IE's implementation.”

>> In short, no, because I don't think half the web misuses floating - but
>> let's say 1% of the web does misuse float - that's a significant
>> blocking problem for us,
>
>I presume that it is a serious blocking problem for other browser vendors
>too.

No, I think they've successfully ignored that compatibility problem.

>> - so if we fix our bugs, the patches no longer work and now
>> damage the site, because authors are EXPECTING us to be broken.
>
>It depends on what switch is used. Authors can use <!--[if lte IE 7]> and
>then you could still fix your bugs in IE8.

But authors won't add that magically.  We need to work with deployed content the day we ship.

>If you do fix bugs and update regularly then perhaps authors' expectations
>changes over time.

Indeed.

>Could you elaborate on how the current definition of <object> wouldn't be
>implementable in IE, and what you would need in order for it to be?

We rely on classid and codebase to load ActiveX controls.

>> (And y'all seem to get quite upset when we add proprietary features and
>> attributes.)
>
>Innovation is good, but sometimes it's better to bring it to the table and
>discuss it in the WG and get it specced and implemented at the same time,
>than first being implemented and then reverse engineered and then specced.

No one else is interested in loading ActiveX controls, I believe.

>>Whitespace handling is different in IE today?  Bummer.  Sorry.  We broke
>> pages when we tried to change it in days of yore.
>
>Is this something the HTML5 spec says anything about (parsing)? What would
>you need the spec to say instead?

Ian would know better than I, I imagine.  Perhaps HTML5 now DOES say exactly what IE does, and the other browsers plan to copy it.  It's goofy in some corner cases, I know, but I'm afraid the details will have to be dug up.

>> I believe our (IE's) only tenable answer (to satisfy the goals of 1)
>> don't break the web, and 2) improve our standards compliance) is that we
>> must require that document authors opt in to standards compliance.
>
>This doesn't help to get interoperability on today's content,
>unfortunately.

Nope.  Sorry, nothing will help there other than every other browser reverse-engineering the bugs and foibles of the browser that (a huge amount of) the current set of web content was designed with - IE6.

>The net effect though is that any new browser has to implement both quirks
>mode and standards mode in order to render the Web.

Today, yes.

>In my opinion it
>would have been better to specify the quirks mode back then, make that
>compliant, and only have one rendering mode. Then it would be easier to
>write a new browser from scratch.

You're optimizing around writing a new browser from scratch.  I'm optimizing for continuing to work with all content we currently work with, with an opt-in to allow "clean" content that I hope will become extremely widely adopted (though I recognize if we screw that one up too, we will need to cycle again).

>> Unfortunately, "standards mode" is too widely adopted now, and we break
>> too much compatibility if we change our UA behavior there,
>
>Indeed.
>
>> so its time has come.
>
>I don't understand this part.

== We cannot significantly change our behavior when we are handed the common content that today falls under "standards mode" (e.g., content with a valid HTML 4.01 Transitional DOCTYPE).

>> Y'all better get working on that ActiveX support.
>
>AIUI, ActiveX would only work under Windows, so that wouldn't be realistic.

As facetious as I was being, actually, I believe ActiveX is implementable on at least the mac.  I think Mac IE5 actually supported it.  The controls weren't cross-platform, but then neither are <embed> handlers.  And we're not the only Windows browser, either.

>> The Microsoft IE team is committed to implementing standards
>> compliance.  At the same time, we can't change current behavior for
>> current content.  That paradox requires us to require authors to opt in
>
>...or we define the spec in a way that you can implement without authors
>having to opt in.

Yes.  But I think our bar for "no breakage" would be considerably higher than that of our competing UAs.  I'm not saying that because I want this to be hard for them - personally, I wish we had more consistent, compliant behavior today.  I'm saying it because we (MS) have a responsibility to our customers and developers.

-C

Received on Thursday, 12 April 2007 22:32:54 UTC