Re: Versioning and html[5]

On Fri, 13 Apr 2007 00:32:41 +0200, Chris Wilson  
<Chris.Wilson@microsoft.com> wrote:

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

Since three browser vendors have successfully developed rendering engines  
that operate on a real DOM tree, that suggests to me that today's content  
doesn't rely on the DOM not being a tree (IE's model). If today's content  
doesn't rely on it, the spec can say something sane. (If I'm wrong here,  
then indeed we would have to spec the broken DOM model.)

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

Then make the getElementById spec require that name attributes are picked  
up.

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

We do? I thought that DOM Core was under the domain of the WebAPI WG.

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

Indeed. It would be hard for other browser vendors to change their  
rendering engine structure to not use a strict DOM tree, for instance.

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

Then I'd consider that to be a problem with the CSS 2.1 spec, really.  
(FWIW, I have been thinking about proposing that the Almost Standards Mode  
handling be specced so that browsers can drop their "Full Standards Mode"  
and only have two rendering modes instead of three.) The CSS 2.1 spec  
isn't very useful if the market leader cannot implement it.

>> I presume that it is a serious blocking problem for other browser  
>> vendors
>> too.
>
> No, I think they've successfully ignored that compatibility problem.

Looking at bug reports in the other's bug systems, basically anything they  
do differently than IE is considered a bug in their browser by some  
authors. Their interest in interoperability made them follow the specs,  
but if MS can't implement the specs then interoperability can't be  
achieved, and thus the specs are not good enough.

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

Indeed. I think the problem here is basically that authors have used  
<!--[if IE]> to fix IE6 bugs, but didn't think about future versions of  
IE. If IE8 fixes bugs that would break the sites that used that CC, then a  
possible solution would be to make that CC return false (effectively being  
equivalent to "if lte IE 7"). Authors writing new pages could use "if lte  
IE X" with X being the current version of IE, to work around the bugs in  
current IEs. When you have implemented HTML5 completely and correctly  
(perhaps in 15 years or so from now) you could perhaps drop CCs  
altogether, because there would be no need for them.

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

You could continue to do so without the spec defining them. (You would  
support a superset of HTML5.)

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

That's what other browser vendors have been doing the past few years. It's  
also what the WHATWG have been doing so that browser vendors don't have to  
in the future. They could just implement the spec and automatically be  
compatible with IE6 and the Web.

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

Tomorrow also. The dozens of billions of pages on the Web that use quirks  
mode won't go away. There will most likely be new pages that rely on  
quirks mode in the future, too.

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

Yes, but not only. I'm also optimizing around getting interoperability  
between current browsers with today's content.

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

And I'm opposed to introducing new rendering modes, as it makes authoring,  
testing, and developing new browsers a lot harder. For each new rendering  
mode you introduce, you increase the complexity. When you have made the  
cycle a couple of times, it would be impossible for new vendors to enter  
the market, and it would be a lot harder for authors to write for the Web.

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

That's fine. The spec should define whatever is needed to handle the  
common content that today falls under "standards mode" (and, IMHO, quirks  
mode, too). If MS introduce yet another rendering mode (which, as noted  
above, I don't think is a good idea), and content starts to rely on that,  
then the spec would have to define that, too (as it would be needed in  
order to render the Web).

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

Ok. If ActiveX is indeed implementable cross-platform, and a browser  
interested in rendering the Web would have to implement it, then fine,  
let's spec it. I'm not sure it is, though, and IE supporting a superset of  
HTML5 is also fine.

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

If we can find some common ground to get IE and other browsers  
interoperable with today's content, then I think content developers would  
be happy even if some minor things broke.

-- 
Simon Pieters

Received on Friday, 13 April 2007 00:22:05 UTC