W3C home > Mailing lists > Public > public-html@w3.org > August 2007

Re: Distributed Extensibility

From: Henri Sivonen <hsivonen@iki.fi>
Date: Mon, 6 Aug 2007 10:32:37 +0300
Message-Id: <66D98742-76FA-4304-ACD5-B723CD4E53B5@iki.fi>
Cc: Sam Ruby <rubys@us.ibm.com>, public-html@w3.org
To: Philip Taylor <philip@zaynar.demon.co.uk>

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:03 GMT