- From: Sam Ruby <rubys@us.ibm.com>
- Date: Mon, 06 Aug 2007 08:14:05 -0400
- To: Henri Sivonen <hsivonen@iki.fi>
- CC: public-html@w3.org
Henri Sivonen wrote: > On Aug 5, 2007, at 22:42, Philip Taylor wrote: > >> producing an element with name "fb:dashboard" in namespace >> "http://www.w3.org/1999/xhtml". > ... >> Tools which feed into an XML pipeline can do whatever they want for >> mapping certain elements into real namespaces. > ... >> I expect this may be insufficient, but in what ways? > > The main problem is that parsing in text/html browsers and parsing in > server side systems working on XML 1.0 plus Namespaces infosets would > diverge and that the DOM in text/html and application/xhtml+xml browser > code paths would diverge. The ability to treat *conforming* HTML5 as an > alternative infoset serialization is a pretty strong property. I > wouldn't give up on this property lightly. OK, there are a couple of > holes already, but they aren't yet too serious: form feed & vertical tab > (safely mapped to space) and non-NCName attributes on <embed> (don't > occur with real plug-ins). > > If we conclude that adding namespacing that puts elements in a namespace > other than http://www.w3.org/1999/xhtml in the browser DOM when parsing > text/html is unworkable considering compat and if we still want a de > jure extension convention in HTML5, shouldn't we pick a prefix delimiter > that isn't special in XML and in IE but is still in ASCII, allowed in > NCNames and not used in existing HTML elements or attributes? (That > character would be the underscore.) Consider the following XHTML fragment: <a:b xmlns:a='urn'/> This produces a DOM element with the following characteristics: name = 'a:b' localName = 'b' Questions: 1) What would the proposed HTML5 serialization for this DOM be? 2) What DOM would be produced by the HTML5 parser for the serialization produced by #1? Would it differ in a way that affects scripts, CSS, or the like? 3) Does IE support the W3C 'localName' property? I'm not convinced that there is a problem here. - Sam Ruby
Received on Monday, 6 August 2007 12:14:41 UTC