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.
Comments
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.