In the abstract, I like the idea of HTML namespacing. However, their proposed implementation gives me a nasty feeling in the pit of my stomach.
It seems that this proposal would contort HTML to better accomodate XML data, just as other interchange formats like YAML and JSON are taking the stage. Also, a lot of the scripting advantages are already taken care of with HTML 5 custom data attributes. I just don't see the need.
Plus, some of these changes would seriously break compatibility with legacy parsers. The only purpose for this proposal seems to be making life easier for Microsoft programmers.
The problem I have with this, is that the examples provided, e.g.
A HTML document editor adds information about tool settings so that a subsequent editing session can continue with the same settings.
A JavaScript library processes custom tags in a browser and turns them into custom controls dynamically on the page.
A browser wants to allow custom behaviors to be defined in one module and attached automatically to custom elements.
An author includes processing instructions in the document that will be processed by a server before delivering the document to a user agent.
An author runs a tool on a document to add numbering to headings and a table of contents. Running this tool leaves custom metadata tags intact.
can already be pretty easily achieved with the technology we already have.
I don't really see the need for namespaces in HTML. If you need custom tags and attributes surely you are better off going straight to XML and then parsing your data in any number of ways that are already available (XSLT, Javascript, PHP etc. etc.)
I'd agree with this if we were designing something in a vacuum, but XML namespaces already exist, and HTML-only browsers already exist. It's a pain to have this mechanism available in XHTML only. To illustrate why, I think I have a better example than the ones from the proposal:
If you want to use just one namespace-based extension like MathML, then you have to make the whole page XHTML. That changes the way CSS and JavaScript work. It turns previously-uncaught syntax errors into site downtime. It makes legacy browser support more difficult (because, for example, the DOM API is incompatible between browsers that support XHTML and ones that don't).
This proposal would allow me to use HTML for my entire site so that I can support legacy browsers reasonably, but also add inline MathML to some pages for browsers that support it, while using the same stylesheets and scripts across all pages.
It also lets me use namespace-based extensions within content management systems where I don't control the doctype, and it generally improves the ease of moving or sharing content between XHTML and HTML web sites.
That's a pretty good example... except that HTML5 already requires that browsers support SVG and MathML elements in HTML documents without any namespacing at all.
The other problem with adding namespaces to HTML for machine metadata is that HTML5 already supports arbitrary opaque content in attributes whose names begin with "data-". Sure, it doesn't solve the extensibility problem as thoroughly as namespaces would, but it takes a good bite out of Microsoft's use-cases, and maybe the 80% solution is Good Enough.
Sounds nice in theory, but then again, so do most proposals about making stuff more extensible.
There's more examples out there of how extensibility went wrong rather than right. (for example, OpenGL 1.x extensions vs. Direct3D's continually updated core API)
With this kind of proposal, I'd be more convinced if I was presented with practical arguments based on how real people and organizations would use the extensions, rather than theoretical technical advantages of slightly different approaches.
We've had several years of experience with the proposed extensibility syntax, since it's taken directly from XML 1.0 (and XHTML 1.0). Some common real-world uses include SVG and MathML on web pages, and Creative Commons license data (using RDFa) for HTML documents.
The main reason for this general approach is that it works with current (and future) XML vocabularies like SVG.
I'm under the impression that Microsoft doesn't support SVG in IE for political and competitive reasons, and that this proposal isn't going to change that, so I really don't see the point.
I guess I don't really know how proposals like this help move things forward. I'm just your average web developer frustrated by the lack of progress in compatibility between browsers.
> Some common real-world uses include SVG and MathML on web pages
If Internet Explorer supported these in any capacity (e.g. had any support for XHTML), they might be common. But in the "real world" I have experience with, they are vanishingly rare, used mainly in demos and by geeks for their personal sites (e.g. Sam Ruby).
They're requesting the ability for anyone to extend the standard without risking incompatibility with future versions—in exactly the same way that anyone can already extend XHTML 1.0 and XHTML5.
Sam was appointed co-chair (with Chris Wilson of Microsoft) of the HTML working group in January 2009, and I expect he'll be a prominent supporter of some version of this proposal. But the primary editor of HTML5 (Ian Hickson of Google; his co-editor is David Baron of Apple) has so far preferred more limited additions that address specific use cases, such as the "data-" attributes in current drafts, or hard-coded support for specific W3C vocabularies like SVG. His reasons are similar to yours; he hopes that by forcing all extensions to go through the HTML working group, the W3C might prevent implementors from fragmenting HTML into mutually incompatible dialects.
While I agree that in the common case entensibility will often be used for evil, it can also drive progress and innovation.
To play Devil's Advocate though, there are many examples that can be brought out in favor of extensibility.
For one, XMLHtttp was invented by Microsoft back in the IE4 (I believe, though maybe it was IE5) days. The amount of AJAX we use today was entirely possible back then, as long as you were willing to limit yourself to the Microsoft browser.
If you always limit yourself to the standard, you'll never end up moving forward. The IE5 spec timeline only projects a finished spec in 2020. Do you think that by 2020 we won't have leapt leaps and bounds ahead of what the HTML5 spec aimed to standardize?
It seems that this proposal would contort HTML to better accomodate XML data, just as other interchange formats like YAML and JSON are taking the stage. Also, a lot of the scripting advantages are already taken care of with HTML 5 custom data attributes. I just don't see the need.
Plus, some of these changes would seriously break compatibility with legacy parsers. The only purpose for this proposal seems to be making life easier for Microsoft programmers.