[whatwg] Possible compremise for namespaces in html5

You understand things correctly. What you propose was also suggested  
by several people at tpac and may well be the right approach.

The argument in favor of colon was that it might fit better with the  
existing namespace way of doing stuff in XML. But it's not clear that  
that is really the case.


-Rob

On Nov 6, 2009, at 2:47 AM, Henri Sivonen <hsivonen at iki.fi> wrote:

> 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/
>
>

Received on Friday, 6 November 2009 06:56:55 UTC