- From: Henri Sivonen <hsivonen@iki.fi>
- Date: Mon, 6 Aug 2007 10:32:37 +0300
- To: Philip Taylor <philip@zaynar.demon.co.uk>
- Cc: Sam Ruby <rubys@us.ibm.com>, public-html@w3.org
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.) -- Henri Sivonen hsivonen@iki.fi http://hsivonen.iki.fi/
Received on Monday, 6 August 2007 07:32:49 UTC