[whatwg] Possible compremise for namespaces in html5
hsivonen at iki.fi
Fri Nov 6 02:47:11 PST 2009
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
> 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 ...
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
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
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?)
hsivonen at iki.fi
More information about the whatwg