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

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

From: Maciej Stachowiak <mjs@apple.com>
Date: Sat, 03 Oct 2009 06:46:39 -0700
Cc: Julian Reschke <julian.reschke@gmx.de>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
Message-id: <A097C41B-7112-4B17-BAA3-04B64AF69061@apple.com>
To: Sam Ruby <rubys@intertwingly.net>

Some minor corrections:

On Oct 3, 2009, at 6:23 AM, Sam Ruby wrote:

>
> It is my belief that if a new syntax would be proposed, it would end  
> up being yet *another* syntax to be supported.
>
> The spirit of my proposal is to see if there are any new APIs  
> needed, or if any of the existing APIs should be modified in order  
> to help tools which intend to mine content which contains what I  
> will refer to as a n "xmlns inspired" syntax in the context of HTML.
>
> Given Phillip's document referred to in:
>
> http://lists.w3.org/Archives/Public/public-html/2009Oct/0067.html
>
> The current HTML5 Working Draft proposes:
>
> 1) IE, Firefox, and Safari to change what they return for nodeName.

Firefox and Safari agree with HTML5 on nodeName in Philip's sample  
document. Opera does not. It should be uppercase.

> 2) IE and Firefox to change what they return for localName.
> 3) IE to change what it returns for prefix.
> 4) IE, Firefox, and Opera to change what they return for namespaceURI.

Note: these statements would also mostly apply in the case of an  
ordinary HTML element, except that IE would match the spec for nodeName.

>
> Tony's proposal:
>
> 1) IE, Firefox, and WebKit to change what they return for nodeName.
> 2) Firefox, Opera, and Safari to change what they return for  
> localName.

And IE.

> 3) Firefox, Opera, and Safari to change what they returns for prefix.

And IE.

> 4) IE, Firefox, and Opera, and Safari to change what they return for  
> namespaceURI.
>
> While it is worth noting that nobody has proposed changing what the  
> results of parsing documents served as XHTML returns, Tony's  
> proposal is to close rather than expand the gap between the  
> processing of HTML and XHTML.
>
> Additionally, there may be merit in discussing whether or not tagUrn  
> should be documented and implemented (perhaps in a separate spec,  
> and perhaps only in JavaScript in some implementations).

I believe it's not possible to implement tagUrn in a way that matches  
IE, using pure JavaScript and existing DOM APIs. Or at least, I don't  
believe walking the ancestor chain will do it.

Regards,
Maciej
Received on Saturday, 3 October 2009 13:47:15 UTC

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