- From: Maciej Stachowiak <mjs@apple.com>
- Date: Sat, 03 Oct 2009 06:46:39 -0700
- To: Sam Ruby <rubys@intertwingly.net>
- Cc: Julian Reschke <julian.reschke@gmx.de>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
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