RE: Versioning and html[5]

Simon Pieters [mailto:zcorpan@gmail.com] wrote:
><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.)

Well, there you go.  No, we could not break the DOM tree fixups we do when faced with HTML 4.01.  It breaks the web.

>> We (HTML WG) own DOM too.
>
>We do? I thought that DOM Core was under the domain of the WebAPI WG.

I should have said "we own object model as well", not to imply we own all the DOM.  Actually, I don't think any present group really owns DOM.

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

Yes.  And I'm not trying to force you to.

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

Note that "if Microsoft can't implement the specs" needs the clause "because it passes the 'breaks the web' bar for them" attached at the end.

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

DING!  Winner!  Yes, that is precisely the problem.  Actually, many of them didn't even use conditional comments.

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

When we implement HTML(n) correctly is irrelevant.  When authors stop relying on our old behavior is.

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

Ummm, we've fallen into THAT trap before.  Some would clearly say supporting a "superset" of a standard by adding (non-namespaced) attributes and elements is actually "throwing your own proprietary stuff in there because you don't believe in standards."

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

Umm, not quite, because they've also removed some stuff we rely on (ActiveX, e.g.) that creates the "Microsoft IE platform" if you will, and they haven't required a bunch of other wacky behavior (aforementioned getElementByID, non-trees, etc.)

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

You're strengthening my point that we can't change our current IE behavior at all, then.

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

Then the other browsers should work on replicating IE's behavior everywhere.

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

Well, then I'd recommend ignoring what IE is doing (adding opt-ins to not break back-compat), and making sure there's a clearly identifiable identifier on new HTML content (because then we can auto-opt-in IE).  I would not recommend trying to get Microsoft to change its current IE behavior on current content, because it's not going to happen.

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

Heheheh.  I expect there's a religious war waiting there.

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

Content developers will never be happy if anything breaks, and they will blame us.  We CAN make our browsers interoperable in the future.  If you want other browsers to be interoperable with today's content, there is nothing else for it than for them to go implement all IE's bugs and foibles as currently released.

-C

Received on Friday, 13 April 2007 21:35:33 UTC