W3C home > Mailing lists > Public > public-html@w3.org > October 2009

RE: ISSUE-41/ACTION-97 decentralized-extensibility

From: Adrian Bateman <adrianba@microsoft.com>
Date: Sat, 17 Oct 2009 18:15:58 +0000
To: Tony Ross <tross@microsoft.com>, Jonas Sicking <jonas@sicking.cc>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <104E6B5B6535E849970CDFBB1C5216EB061EFCF0@TK5EX14MBXC140.redmond.corp.microsoft.com>
On Thursday, October 15, 2009 6:37 PM, Tony Ross wrote:
> On Thursday, October 15, 2009 at 3:49 PM <jonas@sicking.cc> wrote:
> > I think it's very hard to put an exact number on this. Or indeed to
> > measure an exact number. I do definitely agree that some breakage is
> > acceptable though. I'm personally often in the camp that thinks that
> > breakage is more acceptable than others. My strategy is generally to
> > try to deploy a desired change in alpha and beta releases, and see if
> > people complain.
> >
> > My experience has actually been that Microsoft has been more
> > conservative here, though I'm very happy if that is not the case (or
> > no longer is the case). Is microsoft ok with this breakage for the
> > default "compatibility mode"? Or only for example if the document uses
> > the doctype specified by HTML5, i.e. <!DOCTYPE html>?
> 
> I agree that the real challenge is measuring the impact. Yet it's often
> easier to measure the set of sites that might be affected as opposed to
> those that actually break. A rough threshold could help determine when
> the list has been narrowed far enough. Of course as you mentioned, the
> real measure is whether people complain.

Obviously we debated what should go into the document that Tony prepared
in the team at Microsoft. We evaluated what IE currently does with
namespaces in HTML and considered if and how to simplify it. We thought
about what inferences we might draw about compatibility from the fact that
IE currently does process content with xmlns. We recognised that some of
the differences between IE behaviour and a more simplified approach would
cause compatibility breaks.

Some of the feedback I have seen about our submission states that we
didn't do a very good job of documenting current IE behaviour but this
is by design. For example, IE currently doesn't support the DOM APIs that
support namespaces but having these work with custom elements is a key
part of what Tony has described. Our goal isn't to standardise current
IE behaviour - it's to try to help solve the problem of decentralised
extensibility of the HTML language, which we believe is important for the
general use of the language (including outside a web browser).

Jonas wrote:
> Is microsoft ok with this breakage for the default "compatibility mode"?

Our default mode for Internet content (with a standards doctype) is our
standards mode. As we improve support for standards we may break some
existing content (for example, improved CSS 2.1 support in IE8 broke
content that relied on our less capable CSS engine from IE7). We make
a compatibility mode available that pages, sites, or users can opt-in
to when necessary because of these changes. This is our mitigation for
the times when our default standards mode encounters this issue. The
short answer to the question is that we won't break in compatibility
mode but we could be okay with it in the default standards mode.

I'm not suggesting that the approach we have outlined sets the
compatibility bar in exactly the right place. As Tony has mentioned,
we're interested in a discussion to figure out what the right bar is.

Cheers,

Adrian.
Received on Saturday, 17 October 2009 18:16:55 GMT

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