W3C home > Mailing lists > Public > public-html@w3.org > September 2012

RE: [HTMLWG] CR Exit Criteria redux

From: Adrian Bateman <adrianba@microsoft.com>
Date: Wed, 26 Sep 2012 14:32:10 +0000
To: Henri Sivonen <hsivonen@iki.fi>
CC: Maciej Stachowiak <mjs@apple.com>, Boris Zbarsky <bzbarsky@mit.edu>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <aee0fe3ead2e4502b16af56d11471433@BL2PR03MB604.namprd03.prod.outlook.com>
On Tuesday, September 25, 2012 11:07 PM, Henri Sivonen wrote:
> On Tue, Sep 25, 2012 at 5:20 PM, Adrian Bateman <adrianba@microsoft.com> wrote:
> > I'm not yet convinced that it is a good idea to conflate determining that the spec is of
> > sufficient quality to support independent interoperable implementation with determining
> > that the feature is compatible with the existing web.
>  A specification for which independent interoperable implementations
> can be written is not useful for the Web if it is not compatible with
> existing Web content.

I did not state that a spec that is incompatible with the web is desirable. I said that
mixing the two problems is something I'm not convinced is valuable.

> > Those seem like distinct problems,
> > the latter one being approached differently by different organisations and with different
> > tolerances to incompatibility.
> I think one of the main risks of letting spec text get to REC in a
> Web-incompatible state is that Microsoft implements said spec text as
> a new mode in IE so that the new mode doesn't need to be compatible
> with existing Web content and other browser developers are then faced
> with the problem of not interoperating with IE, breaking the Web or
> getting burdened by the cost of adding new modes.

I think one of the main risks of getting spec text to REC in a Web-incompatible
state is that any browser might implement it causing web developers to write
browser sniffing code. As far as I can tell, Microsoft is one of the most
sensitive organisations when it comes to compatibility. We spend a lot of time
crawling the web testing compatibility for changes we make. It's our desire
for both compatibility and interoperability that resulted in different document

But anyway, even if your concern was valid, I think addressing the question
of web compatibility is better addressed separately than implementability and
in fact better addressed even before implementation when possible.
Received on Wednesday, 26 September 2012 14:33:41 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 29 October 2015 10:16:27 UTC