W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2009

[whatwg] Possible compremise for namespaces in html5

From: Rob Ennals <rob.ennals@gmail.com>
Date: Thu, 5 Nov 2009 16:50:35 -0800
Message-ID: <79F24AF7-3C05-4FE5-B115-3BD2C887F37C@gmail.com>
[this is Ron Ennals from Intel, posting from gmail on my phone while  
at tpac]

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


I believe this satisfies the most important requirement for the people  
who like namespaces and the people who don't. In particular:

Reasons why namespaces etc are good:
* allow data on a page without worrying about name clashes
* copy and paste data from existing XML files into HTML
* support markup like fbml, rails, etc - on the client as well as server
* allow companies to include their own XML data inside an HTML file,  
for processing with other tools

Reasons why namespaces are bad:
* copy and paste breaks
* the meaning of a tag depends on what namespaces you have
* the encourage incompatible extentions to the browser
* long namespace urls are horrible

I've pitched this idea about a bit and got tentative buy in from some  
(but not all) people on both sides of the namespace divide.

This idea is unashamedly derived from Liam Quin's similar proposal,  
tweaking the bits some people didn't like.


Comments/bugs/stupidities... ???


[I'll probably post this to public-HTML too later, but I can't do that  
from gmail on my phone]

-Rob
Received on Thursday, 5 November 2009 16:50:35 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 22 January 2020 16:59:18 UTC