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

Intent to Conform (was Re: Version information)

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 9 Apr 2007 09:16:51 -0700
Message-Id: <BB384DBA-FE95-4251-8C29-D74B64C37691@apple.com>
Cc: Lachlan Hunt <lachlan.hunt@lachy.id.au>, "public-html@w3.org" <public-html@w3.org>
To: Chris Wilson <Chris.Wilson@microsoft.com>


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:15:08 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:38:42 UTC