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

On Oct 1, 2009, at 1:22 PM, Adrian Bateman wrote:

> On Thursday, October 01, 2009 11:53 AM, Maciej Stachowiak wrote:
>> On Oct 1, 2009, at 11:05 AM, Adrian Bateman wrote:
>>> Currently, IE doesn't support the DOM APIs related to namespaces.
>>> Currently the other browsers support these APIs but don't have a
>>> mapping to the HTML serialisation (and don't process the xmlns in
>>> the way IE does). This proposal aims to bring the two together. It's
>>> true that we're not aware of a current implementation that does  
>>> both.
>>
>> Besides the different DOM, IE doesn't seem to do any namespace
>> processing of attributes. Thus, the following paragraph in the
>> proposal seems incomplete:
>>
>> "The proposal as stated closely matches behavior that Internet
>> Explorer has had for a number of releases, reducing compatibility
>> concerns. While true that Internet Explorer does not currently allow
>> prefixes to be defined anywhere other than the root element in the
>> document, lifting this restriction is not believed to present any
>> significant compatibility risk."
>>
>> There seem to be a lot of differences besides lifting the root  
>> element
>> restriction.
>>
>> It would be good to document what IE actually does, so we can clearly
>> understand the differences and assess the compatibility impact.
>
> IE has some arbitrary restrictions today. Most of these are based  
> purely on limitations in the implementation of our current DOM and  
> what we proposed removed those restrictions (for example we had  
> nowhere to store the namespace relationship on our attributes).
>
> We talked about many of the limitations in the discussion with the  
> HCG:
> http://lists.w3.org/Archives/Member/w3c-html-cg/2009JulSep/0075.html
> http://lists.w3.org/Archives/Member/w3c-html-cg/2009JulSep/0086.html
>
> The key differences:
>
> * We don't support nested namespace declarations where one should  
> override another
> * We don't support the namespaces on attributes
> * We only allow prefix declarations on the root element

Here's a few more differences; I suspect more would be found with  
deeper study:

* In IE the localName, prefix and namespaceURI attributes whose values  
are given by the proposal are entirely missing.
* In IE, a tagUrn attribute that's not in the proposal is present,  
holding the namespace URI.
* in IE, the nodeName attribute value does not match what is proposed.
* IE will not treat elements with localNames that match an existing  
HTML element as the relevant HTML element, even if it has a namespace  
prefix - the proposal does not include that behavior.

> These were generally limitations from a time/resources perspective  
> rather than a conscious choice for compatibility. Of course, they  
> could be considered as alternatives to the proposal document.

It sounds to me like the proposal is pretty radically different from  
what IE does. I think it's misleading to imply that the Web  
compatibility impact of the proposal is known and likely to be low  
because it "closely matches behavior that Internet Explorer has had  
for a number of releases".

Example: do we know how common it is for current text/html content to  
have a namespace declaration somewhere other than the root element?  
All such content would behave differently under the proposal than in  
IE, in ways that may break intended behavior. Past studies (for  
example, looking for copy-paste embedded SVG in text/html) imply this  
may be fairly common.


Regards,
Maciej

Received on Thursday, 1 October 2009 20:55:22 UTC