[whatwg] Possible compremise for namespaces in html5

[Henri Sivonen]

On Nov 6, 2009, at 02:50, Rob Ennals wrote:

> I've talked to a few people about the distibuted extensibility  
> problem and I'd like to suggest a possible compremise:
>
> * maintain a central registry of prefixes with standard meanings -  
> so eg fb always means fbml. Thus no namespace decl is needed.
> * for a prefixed node the prefix is itself the namespace - thus the  
> user agent doesn't need to know what a prefix means
> * prefixes are allowed for tags and attributes
> * a web browser MUST ignore prefix tags and attributes - they are  
> for data, just like microdata and data attributes, not for browser  
> extensions
[...]
> Comments/bugs/stupidities... ???
[Quoting a subsequent email.]
> This would break some existing practices, but those are arguably bad
> practices and should be changed. E.g. in Lift you can write:
> <lift:surround with="default" at="content">
>   ... some HTML ...
> </lift:surround>


So currently, given <lift:surround>, the HTML5 parsing algorithm  
creates an element node whose namespace is "http://www.w3.org/1999/ 
xhtml" and whose local name is "lift:surround". However, it's  
impossible to represent this kind of element in XML 1.0.

Do I understand correctly that you are suggesting it would create an  
element node whose namespace is "lift" and whose local name is  
"surround"? (Thereby requiring xmlns:lift='lift' when used in XHTML5.)

If so, what is the benefit of your proposal compared to the following  
scheme?

  1) Names that contain the hyphen (-) character are extension names.
  2) Extension element names are in the "http://www.w3.org/1999/xhtml"  
namespace for the purposes of DOM Level 2 or the Infoset.
  3) Extension attribute names are in no namespace for the purposes of  
DOM Level 2 or the Infoset.
  4) The prefix "aria" is reserved for ARIA.
  5) The prefix "http" is grandfathered as a reserved non-extension  
(for http-equiv).

Hence, given <lift-surround>, you'd get an element node whose  
namespace is "http://www.w3.org/1999/xhtml" and local name is "lift- 
surround". This element can be represented in XML 1.0. Furthermore,  
this scheme wouldn't require changes to either HTML or XML parsing.

As far as I can tell, this scheme would put as much information in the  
DOM as your scheme. However, this scheme has the upside that it  
doesn't require any parser changes (Degrade Gracefully) and produces  
the same DOM in both text/html and application/xhtml+xml (DOM  
Consistency). This scheme has the political downside that it doesn't  
use the colon or vary the namespaceURI DOM property.

This scheme also has the downside that you can't use existing  
wildcarding mechanisms for selecting all elements that come from the  
'lift' extension, but the use cases for such wildcarding seem to be of  
questionable utility to me. Especially when you stipulate that  
extension subtrees wouldn't mix standard elements, it seems sufficient  
to select on the root of the 'lift' extension subtrees and then  
traverse the subtrees.

(Of course, all of the above is just a syntactic hypothetical. It  
isn't clear to me what use cases are being addressed. Has Facebook  
reported the lack of a formally blessed way of doing FBML as a problem?)

-- 
Henri Sivonen
hsivonen at iki.fi
http://hsivonen.iki.fi/