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.

This is a fantastic idea.

I suggest also quoting Postel’s Law:
“Be conservative in what you do; be liberal in what you accept from others.”

Posted by John Heintz at

Two minor nits, under “Implications":

The intent of this proposal is not to make all XHTML pages automatically HTML5 compliant, as such would be possible.

This confused me, but maybe I’m missing something.  Did you mean "as such would be impossible"?

This proposal does, however, increases the size of the profile of XHTML...

Should be "increase the size”.

Posted by Will at

Two minor nits

Fixed.  Thanks!

Posted by Sam Ruby at

Sturgeon’s law : [link]


Sturgeon’s Law : [link]

Posted by Peter van Kampen at

-> Sturgeon’s Law : [link]

Fixed.  Thanks!

Posted by Sam Ruby at

This is out to be a good thing

Perhaps "This is thought to be a good thing"?

Posted by pauldwaite at

This is out to be a good thing

Originally, I meant s/is/turns/, but perhaps s/out to be// would be better.

Bah.  Perhaps I should convert this page into being a wiki.  Might be easier.

Posted by Sam Ruby at

Adapting existing GUI tools to (say) emit prefixed SVG is no more difficult than getting those same tools to emit <svg:rect></svg:rect> instead of <svg:rect/>.

Changing the parsing model to accommodate void element syntax on extension elements may not be worth the trouble.

There is always the issue of cut&paste of existing (non-prefixed, void element-containing) content. But this proposal is not going to really facilitate that either way.

Posted by Jacques Distler at

An out of topic comment that triggers in my mind every time I read about HTML5 :

I wish HTML5 where more focused on the Text part of HTML. I wish that Donald Knuth’s work could somehow be leveraged a bit more than on that obsure text formatting language named TeX. I don’t know his work well, but the base of HTML is Text with hyperlinks and it seems just sane to me to not overlook the long standing knowledge of the typographist’s. Why is that we want fancy web applications with crappy 1990 fonts ?


Posted by Jonas Pfenniger at

Adapting existing GUI tools to (say) emit prefixed SVG

Take a stroll through FBML.  Count the number of “/>” occurrences on that page alone.  What tool do people use to produce FBML?  (Hint).

Posted by Sam Ruby at

zimbatm, that’s in the realm of CSS.

Posted by Anne van Kesteren at

I take your point about hand-authoring.

But I’m not so eager to use FaceBook’s templating language (or, for that matter, MovableType’s) as a model for extensions to HTML. Just because the syntax looks very HTML-like, it’s still something intended to be interpreted locally, rather than sent over the wire. I mean, you wouldn’t dream of trying to make raw PHP code consumable by an HTML5 parser, would you?

A better example might be something like MusicML, which, one imagines, could be included in a web page and played by an MML-compatible MIDI plugin.

Or ChemML.

Or ...

Obviously, you are not going to find something that’s, currently, widely deployed on the open web. But that’s the point, isn’t it?

Posted by Jacques Distler at

Lookie there: yet another one.

Some templating languages are meant to be orthogonal to their input syntax.  Others are meant to be embedded.  I’d like the latter types to be able to reuse the HTML5 parser.  I’d like to see conformance checkers for HTML5 be able to verify namespaced additions, much like the feed validator does today.  Even if those namespaces aren’t intended to be sent over the wire (at least not to a browser, FBML is sent from the application provider to FaceBook’s servers).

Why?  Because authors of templates make mistakes too.  And with so many moving parts, it is hard to track down where the error really lies.

I can also imaging a facebook sanitizer, or pretty-printer or...

Posted by Sam Ruby at

Sam Ruby: HTML5 and Distributed Extensibility

Sam Ruby: HTML5 and Distributed Extensibility by znarf html Copy | React (0) [link]...

Excerpt from Public marks from user znarf at

"Some templating languages are meant to be orthogonal to their input syntax."

I’m finding this hard to parse. Did you mean 'output syntax'?

Posted by Michael R. Bernstein at

I meant input syntax.  I heard this term first used in the context of Velocity.

Languages like DOJO, CFML, and Genshi express templates in terms that are a natural extension of underlying XML grammars.  Template languages like Velocity are completely independent of any such considerations.

Posted by Sam Ruby at


Proposing general rules for extending HTML for non-standard purposes...

Excerpt from at

Interesting Start

For the moment, this issue hasn’t even been added to the list of issues that “Ian has marked as needing to be dealt with”.  I hope that this can be corrected.... [more]

Trackback from Sam Ruby


This is indeed a fantastic idea. Let’s hope it shows up on Hixie’s list ASAP!

Posted by Asbjørn Ulsberg at

links for 8/22/2007

Sam Ruby: HTML5 and Distributed Extensibility Some technologies just won’t die… IE XRay Definitely not as useful as Firebug, but between this and this tools for heavy Ajax in browsers other than Firefox are slowly getting there....

Excerpt from at

Hear, hear. This is one of my big problems with HTML4; in practice, it’s extensible, but if you actually care about conformance, it’s not.

Posted by Mark Nottingham at

David Orchard: The TAG has reviewed the proposal ... In short, we believe it is a very interesting start of a proposal for stronger support for distributed extensibility on the web in the HTML language.  We hope that the Working Group will give it and it’s natural subsequent refinements or similar alternatives very serious consideration.

[Manual TrackBack]

Posted by Sam Ruby at

SVG in MathML in ...

On mixing SVG and MathML....

Excerpt from Musings at

TPAC 2007 - URI-Based Extensibility: Benefits, Deviations, Lessons-Learned

The Technical plenary day is continuing. Someone in a comment earlier asked what TPAC was. TPAC means Technical Plenary and Advisory Committee meeting. All W3C Working groups and representatives of W3C are meeting. This year we open a bit more the...

Excerpt from W3C Q&A Weblog at

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

Well they are becoming right? They are proxy-browsers. as in Google becomes one too if you think of the snippets resoults only and if you assume the snippets can be more semantic over time.

Posted by Marcio at

I think that custom, non-standard attributes are useful in Unobtrusive JavaScript.

I for example am working on a e-mail address obfuscation JavaScript called Encrypted E-mail. There I need a way to hand over the script the RSA encrypted e-mail address. Currently I use a stupid hidden field for this, but I think a non-standard attribute would be better.

A second big usage would come from Microformats. Here they have the problems with there abbr-design-pattern.


Posted by Alexander Kiel at

Does C# 3.0 Beat Dynamic Languages at their Own Game?

For the past few years I’ve heard a lot of hype about dynamic programming languages like Python and Ruby. The word on the street has been that their dynamic nature makes developers more productive that those of us shackled to statically typed...

Excerpt from Dare Obasanjo aka Carnage4Life at

Comments, REST, Interactions, and Extensible Hypermedia

This post is to mostly keep track of the numerous blog threads going on about IDLs and schemas for REST. I find myself with more to say that wit to organize it... :( First my summaries of opinions, then links to my comments here and there. Some of...

Excerpt from An Opinion? Well, if you ask... at

Namespaces in IE 8 Beta 1


Excerpt from Dave Orchard's Blog at

TAGSoup: Namespaces in HTML and HTML5 WG


Excerpt from Dave Orchard's Blog at

Fake Smile

David Leunen has released a new JavaScript library to fake SMIL for modern browsers that don’t yet support declarative animation (Firefox 3.0- and Safari 3.0-). The nice thing about this is that it uses existing standards, so that when...

Excerpt from Something Witty Goes Here at

Distributed Extensibility stays alive and Anne

Anne says "Concerns that HTML5 does not have distributed extensibility. That is, namespaces. What people seem to want is to extend the browser with hundreds of markup languages. (How this keeps things simple to answer was not something I saw......

Excerpt from Dave Orchard's Blog at

A Peek Inside the W3C

I’ve long believed that the Ajax/JavaScript communities and the W3C should communicate more and have more awareness of what both camps are doing so we can work together better and get things done. In light of this, here are some updates on a...

Excerpt from Ajaxian » Front Page at

This strikes me as a horrible, horrible idea. If you want to extend (X)HTML elements, use XML. HTML is HTML. If you’re concerned about giving XML to IE, conditionally serve your content to IE as Content-type: text/html, and deal with the fact that your content is invalid. IE already won’t understand your new tags and new attributes anyways, so you don’t lose anything by doing this. Or you can try some of the crazy javascript methods to try to render XML through XSLT or something. But don’t bulk up an already complicated spec with more cruft.

I understand that specs need to be realistic, but completely mangling together two specs solely to work around IE being a terrible browser just seems to be going too far.

Posted by Brady Wetherington at

First, I will not thate this page is served exactly the way you state.  “Don’t lose anything” is a wee bit of an overstatement, and is a real PITA.

As I said at Shelley’s place, extensibility will happen whether you want it to or not.

Meanwhile, look at how many sites today put XHTML cruft into pages served as text/html.  HTML5 now allows for most of this.

This page is valid XHTML5This page is valid HTML5.  Once SVG support is added to HTML5 again, the two pages will can be byte for byte identical.

Posted by Sam Ruby at

HTML5 += Intertwingly

Sam Ruby has just been appointed co-chair of the HTML5 Working Group. In addition to being an early adopter of HTML5, Sam has been a loud proponent of distributed extensibility within HTML and a vocal critic of the entire HTML5 process in general....

Excerpt from Something Witty Goes Here at

Excellent idea, especially the IANA style registry for common prefixes. That should help make the most common namespaces much easier for most users (and help prevent the copy paste errors you identify and which Hixie found). Big +1 on this proposal.

Posted by Brad Neuberg at

Iz Puttin' Namespaces in Ur HTML5

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

Excerpt from Articles, Opinions & Lab - MIX Online at

Facebook’s Open Graph Protocol from a Web Developer’s Perspective

David Recordon of Facebook has an interesting post titled Why f8 was good for the open web where he talks about how some of Facebook’s announcements at their recent F8 conference increase the openness of the Web. He calls out the following four...

Excerpt from Dare Obasanjo aka Carnage4Life at

Adewale Oshineye: Communicating with atoms

A few weeks ago I attended an Open Source Jam where the topic was “building blocks.” I gave a lightning talk about why the combination of Atom and Webhooks is changing the way web applications interoperate. In this set of blog posts I’d like to...

Excerpt from aggregator at

Communicating with atoms

A few weeks ago I attended an Open Source Jam where the topic was “building blocks.” I gave a lightning talk about why the combination of Atom and Webhooks is changing the way web applications interoperate. In this set of blog posts I’d like to...

Excerpt from Heuristic Outcomes at

Henri Sivonen: and Pre-Existing Communities

I have been reading tweets and blog posts expressing various levels of disappointment and unhappiness about not using RDFa, not using Microformats or not having been developed in the open with the community. Since other people’s...

Excerpt from Henri Sivonen’s pages at

Add your comment