It’s just data

HTML5 and Distributed Extensibility

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:


Update: Added case sensitivity and reserved namespace “messy details” based on feedback from Henri Sivonen.