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