Distributed Extensibility

Original here:

http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed-Extensibility

I welcome responsible and respectful discussion either here on this 
mailing list or in the comments of that page itself.  A plain text 
version of this proposal is included below:


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 structure of the 
DOM that is produced.  This is out to be 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 a qualified 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 protocol has evolved.  That has been key to its evolution.  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 wither 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 
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, and 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 the users get what they deserve.  These 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.

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


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 the 10% of the 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 possible.

     * This proposal does, however, increases 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 increase 
in size by at most a few dozen bytes 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 this 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 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.

Received on Thursday, 2 August 2007 15:16:16 UTC