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.
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.
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 ?
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.
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...
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.
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]
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....
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.
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...
“ 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.
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.
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...
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...
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...
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......
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...
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.
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....
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.
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...
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...
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...
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...
Henri Sivonen: Schema.org and Pre-Existing Communities
I have been reading tweets and blog posts expressing various levels of disappointment and unhappiness about schema.org not using RDFa, not using Microformats or not having been developed in the open with the community. Since other people’s...