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

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

From: Sam Ruby <rubys@intertwingly.net>
Date: Sat, 03 Oct 2009 08:29:28 -0400
Message-ID: <4AC743A8.6050908@intertwingly.net>
To: Philip Taylor <pjt47@cam.ac.uk>
CC: Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
Philip Taylor wrote:
> Adrian Bateman wrote:
>> We have included a base proposal with several optional components. The 
>> purpose of this document is to seed a discussion and we expect the 
>> discussion to drive improvements in the document.
> 
> Looking at just the base proposal for now:
> 
>> HTML Markup:
>>      <my:calendar xmlns:my="com.mycompany">
>>
>> DOM:
>>      Element {
>>           localName    = "calendar",
>>           nodeName     = "my:calendar",
>>           prefix       = "my",
>>           namespaceURI = "com.mycompany"
>>      }
> 
>> The proposal as stated closely matches behavior that Internet
>> Explorer has had for a number of releases, reducing compatibility
>> concerns.
> 
> This claim does not match my experience.

 From an IE perspective, the proposal is to change exactly one API, and 
to do so in a way that aligns completely with the definition in the 
current HTML5 Working Draft, and to implement three APIs that IE had 
previously not implemented.

I can see how somebody could see that as closely matching the behavior 
that Internet Explorer has had for a number of releases.

> For example, 
> http://philip.html5.org/misc/xmlns-dom.html has the input:
> 
>   <html xmlns:foo="http://foo.example.com/" 
> xmlns="http://www.w3.org/1999/xhtml">
> <body><foo:bar></foo:bar>...
> 
> and then prints some DOM properties.
> 
> Output in the proposal above:
> 
> tagName:      ???
> nodeName:     foo:bar
> localName:    bar
> prefix:       foo
> namespaceURI: http://foo.example.com/
> tagUrn:       ???
> 
> Output in IE8 (and in IE7 compat and quirks modes):
> 
> tagName:      bar
> nodeName:     bar
> localName:    undefined
> prefix:       undefined
> namespaceURI: undefined
> tagUrn:       http://foo.example.com/
> 
> Output in Firefox 3.5:
> 
> tagName:      FOO:BAR
> nodeName:     FOO:BAR
> localName:    FOO:BAR
> prefix:       null
> namespaceURI: null
> tagUrn:       undefined
> 
> Output in Opera 10:
> 
> tagName:      foo:bar
> nodeName:     foo:bar
> localName:    foo:bar
> prefix:       null
> namespaceURI: null
> tagUrn:       undefined
> 
> Output in Safari 4:
> 
> tagName:      FOO:BAR
> nodeName:     FOO:BAR
> localName:    foo:bar
> prefix:       null
> namespaceURI: http://www.w3.org/1999/xhtml
> tagUrn:       undefined
> 
> (HTML5 currently matches Safari, ignoring name case issues which I 
> haven't bothered checking. (The namespaceURI doesn't come from the xmlns 
> attribute, it's just the default for HTML elements - the attribute is 
> ignored entirely.))
> 
> Output for http://philip.html5.org/misc/xmlns-dom.xhtml in everything 
> that support XHTML:
> 
> tagName:      foo:bar
> nodeName:     foo:bar
> localName:    bar
> prefix:       foo
> namespaceURI: http://foo.example.com/
> tagUrn:       undefined
> 
> The proposal therefore seems to be completely different to every current 
> text/html browser, as far as the DOM goes. Am I missing something here?

Doing some analysis, Tony is proposing that nodeName be "foo:bar".  This 
represents a change from what Firefox and Safari return (the case is 
different).  It does represent an incompatible change from the current 
IE behavior, but given that it is what html5 specifies, I believe that 
this is not only non-controversial, but also worth commending.

The DOM specification indicates that tagName and nodeName must return 
the same value, and all implementations current respect this constraint, 
so while Tony's proposal isn't explicit about this, I think it is safe 
to assume that this constraint will still hold.

IE8 does not currently implement localname, prefix, or namespaceURI, and 
the proposal describes one possible implementation.

While not explicitly mentioned, I will make the assumption that future 
releases of IE will continue to support tagUrn.

  - - -

This leaves the following questions given Phillip's document:

Should localName be "bar" or "foo:bar"?

Should prefix be "foo" or null?

Should namespaceURI be "http://foo.example.com/" or 
"http://www.w3.org/1999/xhtml"?

Should tagUrn be "http://foo.example.com/" or undefined?

- Sam Ruby
Received on Saturday, 3 October 2009 12:30:09 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:08 UTC