intertwingly

Since the workgroup demands use cases for any proposed new feature, I will provide one up front: this feature’s use case is to enable features without use cases.  But before I proceed, it would be helpful to review a bit of background.

Technical background

In addition to covering how bytes are shipped across the wire and how a user agent may render the result, HTML5 also describes the structure of the DOM that is produced.  This is a good thing.

HTML5 defines two serializations, one largely based on SGML, and one defined by XML.  Neither can capture the full domain of data that is expressible in a DOM (nested paragraphs and comments that contain consecutive dashes are examples).

Central to the DOM is the notion of an element.  An element has a node name, a local name, and a namespace URI.  The local name and the namespace URI may be combined to provide an expanded name.

Consider the following XML fragment:

<x:foo xmlns:x="urn"/>

This fragment contains one element with the following characteristics.

node name = x:foo
local name = foo
namespace URI = urn

HTML5 fully describes how node names are formed, makes a brief mention of namespace URIs, but doesn’t cover local names at all.

Social background

HTML as a format has evolved.  That has been key to its success.  I remember using a browser before <table> was widely implemented, and I remember how that browser reacted to pages that contain tables, which is to say, rather poorly.  But the web has survived, and tables are now part of the standard and are regularly used and misused like all the other tags.

This evolution has occurred based on the notion that user agents are to ignore what they don’t understand.  This has allowed a relatively small number of players the ability to define new tags.  Tags such as blink, marquee, and canvas.  Some become widely adopted.  Others withered and die.  This is evolution in action.  And that’s not a bad thing.

But this is limited to small changes by a small number of players.

A counter example is FBML.  It is defined by somebody who isn’t browser vendor.  It defines a comparatively large set of tags.

FBML isn’t intended to be directly processed by browsers, but that shouldn’t preclude it from being processed by other HTML5 tools, everything from sanitizers to conformance checkers to pretty printers, to search engines.

If we can imagine a world where a large number of people can make such large extensions to HTML, it is incumbent on us to think about how to prevent harmful extension overlap, and how extensions might be processed by user agents that aren’t aware of either that particular extension, or of the notion of extensions itself.

For example, we don’t want facebook’s iframe to be confused with an HTML iframe.  Nor do we want facebook’s definition of an explanation to impede evolution of HTML (witness the problems with object).

We also need to note that people have routinely abused HTML, and that browsers have had to deal with that reality, and that spec writers need to deal with THAT reality.  In particular, one can find xmlns attributes strewn throughout the web.  In a small number of cases, if these attributes were to suddenly become “live”, the rendered output would differ.  We don’t have the luxury of being able to state that input was invalid and therefore those users get what they deserve.  Users have been encouraged to expect that HTML is forgiving, and we can’t unilaterally renege on that expectation.

Outline of proposal

The scope of this proposal is limited exclusively to the definition of the DOM produced by an HTML5 compliant parser.  No expectation is set as to how these extensions will be rendered, if at all.

The notion of allowing multiple independent developers to define extensions to a grammar is not a new one, and the solutions are well understood.  Not necessarily well liked, but well understood.  The solution is some form of namespaces.

Within the scope of SGML-like grammars, a colon has traditionally been used as a separator.  There is no need to violate this expectation.  No existing HTML5 elements contain a colon in them, and prohibiting all future “core” HTML tags from having a colon is not an onerous restriction.

XML permits an alternate syntax, namely default namespaces.  In certain circles, such a syntax is very popular.  Regrettably, allowing such a syntax would pose problems for back level user agents, and therefore must be disallowed in the HTML5 “custom format”.  Disallowing such syntax does not limit distributed extensibility in any way, but does place a limit on the set of DOMs that can be directly expressed in HTML5.

The notion using attributes to define namespaces, and the specific syntax for declaring same, however, can be directly lifted from XML.  The syntax is xmlns:x in an enclosing scope.

So, the net of the proposal is that extension attributes may be permitted on existing tags, but only if the attributes names contain a colon, and the namespace has been previously declared in an enclosing scope.  Similarly, extension elements are allowed under similar circumstances.

Messy details

I don’t pretend that these are exhaustive, but they should seed an interesting set of discussions:

• Use of colons in element and attribute names without a matching enclosing declaration would be a recoverable error.
• I see no reason to restrict extension elements to only having extension attributes.  In other words, attributes without a colon are fine on elements with a colon.
• Mixed case extension element names, extension attribute names, and any other attribute names on extension elements (e.g. svg:svg/@viewBox) will need to have their case preserved when inserted into the DOM.  How to handle names that are purely UPPERCASE will also need to be defined.
• The notion of “enclosing element” is problematic in the face of adoption agency algorithms and the like.  The prudent thing to do is to define any case where reparenting would change the meaning of any element to be a (recoverable) error.  This would affect very few users or documents.  It would be a bitch to code in a conformance checker, but that’s not the spec’s writer’s concern.  :-)
• HTML5 has rules for when to close matched and unmatched open elements, and this proposal doesn’t change that.
• Empty element syntax (self closing tags with a trailing soludus) are popular enough to merit special consideration.  HTML5 allows such syntax for elements like br, but not for script.  Allowing arbitrary extension elements to be empty would address this perceived user need.  But consider the case of an extension element in a head section of a HTML page.  Subsequent elements would be considered to be enclosed in that element by a non-namespace aware user agent.  A narrower change that would capture the majority of the usage would be to allow empty extension elements but only if the immediate parent was also an extension element.  This complicates the parsing state machine a bit, but I’ve never seen a case where a more complicated HTML state machine was successfully used as an argument against preserving backwards compatibility.
• Attributes in HTML5 don’t require quotes around values, and this proposal doesn’t change that.

• You might think that this proposal wouldn’t change how text nodes or comments were processed, but there is one case that merits consideration.  The default processing by existing user agents is to render text nodes even when they are enclosed in unknown markup.  In some cases, this may not be desirable.  The XML CDATA[] syntax is treated as a comment by HTML parsers, so this may be used to “cloak” such text regions.  For this to work, however, HTML5 compliant parsers would have to treat such constructs as text, but only when enclosed by an extension element.  Again, a more complicated parse state machine is necessary in order to preserve backwards compatibility and extensibility.

  Update: this may not be necessary, based on input from Simon Peters.  More investigation is necessary.

• The XHTML namespace itself will be reserved, i.e., not allowed to be mapped to a prefix in HTML5 documents, as any such usage would not be handled by user agents that were unaware of HTML5 namespaces.

Implications

• Sturgeon’s law still applies.  90% of all namespaces are crap.  This proposal doesn’t change that.  Put your faith in Darwin.  Something in 10% of the remaining 10% will knock your socks off.
• My site uses SVG, but not in a way that conforms to this profile.  The intent of this proposal is not to make all XHTML pages automatically HTML5 compliant, as such would be impossible.
• This proposal does, however, increase the size of the profile of XHTML that can be reasonably handled by HTML5 parsers.  I or others could voluntarily chose to restrict ourselves to that profile, but are not compelled to do so.  In my case, a typical page would only need to increase in size by at most a few dozen bytes in order to conform.
• There has been occasional talk of grandfathering in the set of  MathML elements.  While this proposal reduces the need for such an effort, it doesn’t preclude it from happening.
• To make HTLM5 more robust, it may make sense to define a central registry of default prefixes.  This would likely be controversial, but would effectively address a common problem.  Such prefixes would, of course, be overridable in any document; the intent of this is only to handle the case where somebody copy/pastes a document fragment without the enclosing namespace declaration.
• Having the option to make extensions increases the flexibility of the workgroup.  Features with marginal use cases need not be in the core, they can be shunted off to a namespace.
• FBML, which I so prominently featured in my exposition of this proposal, also doesn't completely comply. In particular, it does not define a namespace, it merely uses a prefix. It is my belief that asking the authors of FBML to define a namespace in order to comply (should they wish to), is a reasonable request.