W3C home > Mailing lists > Public > public-html@w3.org > April 2007

RE: Intent to Conform (was Re: Version information)

From: Chris Wilson <Chris.Wilson@microsoft.com>
Date: Mon, 9 Apr 2007 10:59:27 -0700
To: Maciej Stachowiak <mjs@apple.com>
CC: Lachlan Hunt <lachlan.hunt@lachy.id.au>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <5C276AFCCD083E4F94BD5C2DA883F05A27D6D61B26@tk5-exmlt-w600.wingroup.windeploy.ntdev.microsoft.com>

All,
        I need to detail an essay about compatibility and opt-in to explain the Microsoft viewpoint on this.  I have a few things on my plate I must do today, so it will probably take a day or two.  I'm going to likely be silent until then on this topic.

-C
-----Original Message-----
From: Maciej Stachowiak [mailto:mjs@apple.com]
Sent: Monday, April 09, 2007 9:17 AM
To: Chris Wilson
Cc: Lachlan Hunt; public-html@w3.org
Subject: Intent to Conform (was Re: Version information)


On Apr 8, 2007, at 6:01 PM, Chris Wilson wrote:

> Lachlan Hunt [mailto:lachlan.hunt@lachy.id.au] wrote:
>> Chris Wilson wrote:
>>> Yes, we will require opt-ins to turn on "really really" standards
>>> mode in future versions of IE.
>>
>> I do not understand.  The intention of HTML5 is for it to be
>> defined in
>> a way that *is* compatible with the web.  And assuming that is the
>> case,
>> you will be able to implement it because it will not significantly
>> break
>> compatibility.  This is in part because much of the processing
>> requirements were based reverse engineering IE, Firefox, Opera and
>> Safari.  If there is something in the spec that will significantly
>> break
>> compat, then we can revise the spec based on implementation
>> experience.
>
> Opera, Safari and Firefox do not bug-for-bug repeat IE's mistakes.

Not all of them - only the ones that web content has come to depend
on without IE-specific targeting.

>
> Knock yourself out.  To us that's the current behavior of IE, and
> we cannot change it no matter how wrong it may be (and in some
> cases, it's quite provable wrong)*.  I'd like to build an IE that
> accepts standard content, and handles it according to the spec -
> which will allow all UAs to have the same behavior.  Unless we have
> some way to identify that content, we will not be able to change,
> and then we will have to make "the spec" mirror precisely what IE7
> does.  I think that would be an awful spec, and I'd rather create a
> better future.

Just to be clear - which of the following conclusions would be
correct to draw from your statements:

1) IE does not intend to ever fix any content-handling bugs relative
to IE7 without some explicit opt-in (so current web content that does
not add the right opt-in trigger will always render exactly as in IE7).

2) IE does not intend to ever add new features (elements, attributes,
APIs, JS language features, CSS selectors, CSS properties, whatever)
relative to IE7 without some explicit opt-in, even if such support
would not break known web content.

3) Not only will IE not fix current bugs or add features without opt-
in, but for all future standards that IE supports, at some point you
will stop fixing bugs and lock in the then-existing behavior of IE as
a new quirks mode. So, for example, assuming IE10 supports HTML5,
IE11 won't fix any bugs in HTML5 support or add any features you
missed and no more changes will be made until HTML6 is out.

#1 and #2 would be troubling enough -- but even a single post-HTML4
doctype (like <!doctype HTML> as proposed by Web Apps 1.0) would
enable adding a single new quirks mode switch.

But if #3 is the case, then you are effectively announcing that IE
does not ever plan to conform to any standard this working group
comes up with. At some point, a given set of bugs will be frozen. And
IE will not document these differences and ask for errata to the
spec, they will just remain an IE-specific set of arbitrary differences.

I hope #3 does not apply, because that would make Microsoft's
participation in this Working Group appear to be in bad faith.
Normally implementors participate in Working Groups to negotiate a
standard they can all reasonably implement. In the end, everyone
compromises for the greater benefit of interoperability.

Saying up front that you will never be conformant seems to me like an
unfair way to approach this process. After all, if HTML5 called for
something that was exceedingly impractical to implement, it wouldn't
really matter to Microsoft - that can just be a future quirk. But
other browser vendors, who do intend to keep improving conformance,
would have to either struggle with it or get the spec changed. Given
this disparity, it is hard to see how fair compromises could be
negotiated.

So, once again, I really hope that #3 is not something you mean to
imply by your remarks. While feedback from a vendor who does not
intend to conform to the standard may be somewhat interesting, it
should not be given the same weight, I think, as feedback from
vendors who do intend to conform.

To be fair, it's probably the case that no existing browser has 100%
conformance to any web standard. But for Safari at least, we fix
conformance bugs regularly. And if we discover that something in a
web standard significantly breaks web content, we try to get it
changed. I believe this is the case for Mozilla and Opera as well. I
think this is a very different stance from deciding to have an
arbitrary undocumented set of deviations from the spec that are not
fed into the standards process.

Sincerely,
Maciej
Received on Monday, 9 April 2007 17:59:41 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:15:52 GMT