A few weeks after I wrote about "The HTML5 Semantics Debate", the Internet Explorer team sparked an exciting discussion with a proposal for extensibility in HTML5. IE’s proposal seems to have been inspired by Sam Ruby's proposal from 2007, and suggests a few different ways to make HTML5 extensible.

The proposal was welcomed by some, while others were not so charitable:

[01:49] * tantek is resisting the temptation to write a massive "bitch-slap" (technical term) email to public-html in response to the proposal. (Microsoft people ought to know better)

It's an absolutely fascinating discussion, and worth reading all of the posts. Opinions are all over the map on this one.

When I wrote about this issue last month, I felt that formal specification would be a waste of time, arguing that people could simply continue using one of the existing "hacks" for extensibility. But this recent discussion has highlighted some inconsistencies in browser behavior which will probably never be fixed unless formally specified.  If I've concluded anything from this conversation, it is that the W3C really ought to formalize a mechanism for extensibility. It really doesn't matter whether the ultimate solution uses namespaces or not, as long as a method is specified. 

We struggled with this exact issue when developing Gestalt. Gestalt enables XAML embedded directly in HTML, and XAML is an XML vocabulary. When Firefox or Chrome parse a document containing XML fragments, the browser automatically converts all tag names to lowercase and improperly nests tags with trailing slashes. Since XML is case-sensitive, and since nesting is important to XML, this ruins the XML. To protect your XML from being molested, you need to either use XHTML or else overload the <script> tag semantics by burying the XML there.

It's easy to imagine why the Firefox and WebKit (Chrome) developers chose to do this. It makes things more convenient for browser implementers. But it's not at all what a page author expects, and is really unfortunate, IMO. As long as the spec leaves details like this up to the implementers, we can expect these inconsistencies to continue. A solid specification for distributed extensibility would make a big difference.

Of course, some have argued that HTML5 should not be extensible, and might argue that browser bugs like the above are good, because they dissuade people from adding "proprietary" junk to HTML. But I'm becoming convinced that Sam Ruby is correct on this point:

I am of the belief that attempts to legislate morality in the long run will be as successful as the 18th amendment to the US Constitution was. I also happen to believe that we can't standardize everything at once, so at whatever point in time we happen to want to take a snapshot for HTML5, there will always be new elements and features (e.g. datagrid) which will not yet be standardized, and planning for evolution is the responsible path forward.