- From: Sam Ruby <rubys@intertwingly.net>
- Date: Sat, 03 Oct 2009 09:23:21 -0400
- To: Maciej Stachowiak <mjs@apple.com>
- CC: Julian Reschke <julian.reschke@gmx.de>, Adrian Bateman <adrianba@microsoft.com>, HTML WG <public-html@w3.org>, Tony Ross <tross@microsoft.com>
Maciej Stachowiak wrote: > > On Oct 3, 2009, at 2:31 AM, Julian Reschke wrote: > >> Maciej Stachowiak wrote: >>> ... >>> That is true. >>> Is it ok that in an XML document, the API would give different >>> answers than the built-in XML namespace mechanism? Would it be >>> acceptable to encourage consumers to process XML content based on >>> "effective namespace URI" instead of based on actual Namespaces in >>> XML processing? >> > ... >> >> I would hope that that API gave the same answers for XML documents, >> and would only differ in HTML. > > Sam suggested an API that is implementable in pure ECMAScript > (presumably it works by looking at ancestor elements to find namespace > declarations). That would not give the same answer for an XML document > as namespaceURI. > >> >>> I suggest that if we introduce a mechanism with different behavior >>> than either Namespaces in XML or IE's HTML namespaces, but usable in >>> the same document at the same time, then it should probably use a >>> different syntax than Namespaces in XML. >>> ... >> >> If Microsoft is willing to *change* their namespace support in HTML, >> and nobody else is implementing it, then I don't see why a new syntax >> would be needed. > > Sam proposed a mechanism that would do namespace binding in a way that > requires no browser support at all and can be implemented in client-side > script if needed. > > I think it's better for a mechanism like that to use a separate syntax, > so there's no risk of interpreting namespaced content in two different > ways. Or maybe three different ways, if IE's model, Sam's proposed new > model, and the XML model may all apply. 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. 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. 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. 3) Firefox, Opera, and Safari to change what they returns for prefix. 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). > Regards, > Maciej - Sam Ruby
Received on Saturday, 3 October 2009 13:24:01 UTC