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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Mon, 9 Apr 2007 11:08:52 -0700
Message-Id: <17B5638B-56B6-4C71-B631-0B857ED6CB5D@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 9, 2007, at 10:59 AM, Chris Wilson wrote:

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

An essay would be great. I hope it includes a clear answer to my  
specific question, since that has direct bearing on how much weight  
we should give to Microsoft's input on pretty much any issue.

Regards,
Maciej

>
> -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 18:09:39 GMT

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