A link to the past

HTML is the Hypertext Markup Language. Hyperlinks is what made HTML special. When I came to the HTML Working Group, shortly after the browser war was over, the feud of the day was with XLink 1.0, which quickly had become a Recommendation through a flawed process. The HTML group wasn't happy about it, as they didn't think the specification fulfilled its design goals.

XLink had a complex history, originally it was meant to be an Extensible Linking Language to complement the Extensible Markup Language (XML). The specification ended up creating a number of attributes in the XLink namespace, 'link:type', 'xlink:href', 'xlink:role', 'xlink:arcrole', 'xlink:title', 'xlink:show', 'xlink:actuate', 'xlink:label', 'xlink:from', 'xlink:to'. The idea was that any XML language needing hypermedia functionality would mix in the appropriate XLink attributes.

When I left the HTML Working Group a few years later XLink was forgotten, but the HTML working group had made a very similar collection of floating attributes for XHTML2, 'xhtml:href', 'xhtml:role', 'xhtml:src', 'xhtml:about' and so on. The idea now was that any XML language needing hypermedia functionality would mix in the appropriate XHTML2 attributes. …

A primordial syntax war

Before XML, even before HTML, there was a syntax war in SGML. While there was broad agreement on the basics of a markup language, that the annotations would be embedded but separate from the content in tags, and that the tagged elements would constitute a tree, there are two different ways of marking up annotations in SGML, XML, and HTML. You can use attributes and you can use elements. But when should you use which? Any information structure could be used with either. Given a marked up element like this:

EXAMPLE 1: 〈FRUIT first="apple" second="banana"〉lunch〈/FRUIT〉

The attributes can be removed by turning them into elements, and there is actually a proposal to remove attributes from the language this way, called Simple Markup Language.

EXAMPLE 2: 
 〈FRUIT〉
   〈first〉apple〈/first〉
   〈second〉banana〈/second〉
    lunch
 〈/FRUIT〉

You cannot truly remove elements, since you need them to generate the tree, there is no attribute equivalent of:

〈outer〉
   〈inner〉content〈/inner〉
 〈/outer〉

However you can take away any meaning or type of elements, leaving them generic.

EXAMPLE 3: 
 〈element name="FRUIT" first="apple" second="banana"〉lunch〈/element〉

Similarly a 'VEGETABLE' element could be coded as 〈element name="VEGETABLE"〉and so on. There are structural differences between elements and attributes. For example attributes are not ordered, this is functionally identical to example 1:

EXAMPLE 4: 〈FRUIT second="banana" first="apple"〉lunch〈/FRUIT〉

while elements are ordered, this example is not functionally identical to example 2, though sometimes this difference may not matter:

EXAMPLE 5: 
 〈FRUIT〉
   〈second〉banana〈/second〉
   〈first〉apple〈/first〉
    lunch
 〈/FRUIT〉

Most people end up in a middle position, that in some cases it is better to encode information using elements, in other cases it is better to use attributes. But how can you determine which is best in a particular case? Some see this as a matter of taste, others as a source for flame wars, in either case it will have a bearing on the performance of the language.

A role for extensibility

The working groups ended up with the same mechanism to introduce hyperlinking to general markup formats, namely add these attributes in the XLink or XHTML2 namespace, and you got yourself a hyperlink. What is the reason for this convergent evolution? Because it is easy, just stick in this attribute here and you got yourself some brand new functionality (assuming it is supported by the user agent).

The problem is that this way to mix in functionality has no conflict resolution. Assume in the examples above that both the 'first' and 'second' attributes tells what kind of 'FRUIT' we are talking about, and that there is no such thing as a banapple. Is the FRUIT an apple or a banana? In the examples 1 and 4 we can't know, while in the cases 2 and 5 we can know if and only if there is a resolution mechanism, the first element trumps the second element in document order, or the other way around. Another example would be

〈link xlink:href="./hither" xhtml:href="./thither"〉where to?〈/link〉

This is a backdrop to the XHTML2 'role' attribute, which may or may not be a good idea, but certainly warrants a second or third look to see if it should be salvaged for (X)HTML5. HTML5 is not a general markup language, so the issue described above would not apply, though it could apply for XHTML5.

The HTML5 'nav' element has been criticised because it could be described with the 'role' attribute. The critique should go the other way. Does 'role' attribute need the 'nav' element and other semantic or structural elements to justify its existence? If the answer to this is "yes" then 'role' has no role in HTML5.

The arguments for 'role' and other XHTML2 is extensibility, and many of these mechanisms are extensible to a fault, but they achieve this by a deep journey of indirection. You will know what you are talking about through resolving and comparing the content of a namespaced attribute value. In comparison you will quickly and clearly know what an HTML5 'nav' element is if and only if you have a preexisting knowledge of that.

HTML5 is not extensible the way XHTML2 is, and I will argue that it is a strength, not a weakness. That doesn't mean that extensibility in itself necessarily is a weakness. Because HTML5 is a fixed format, and HTML without version number is a slowly evolving standard, it is perfectly possible to describe 'nav' and the other HTML features using 'role' or any other metadata approach, and not worry about it flexing too much. A cardinal rule for metadata should be that it is not to stand in the way of data, metadata comes after data.

Extending into the future, what future?

Whenever we buy a rapidly changing technological product, a phone or a TV say, there are always sales people arguing that we should buy a more expensive product because they are already supporting some recently defined standard, functionality, or interface that will be the wave of the future.

My buying strategy through the decades has been to largely ignore that, to buy the cheapest product that fulfil my needs (and my needs are sometimes ahead of the wave and sometimes very basic). The products I have been most dissatisfied with in my lifetime as a consumer have more often than not been the products that are potentially good, but not good right now. It is far better to buy the products when they actually get good.

The same applies to buying into standards. They need to be good now, not in the next world. One of the better quotes from the last weeks' debacles comes from Ian Hickson. It showed an important difference in philosophy between XHTML2 and HTML5.

Originally posted by Hixie:

We don’t need to predict the future. When the future comes, we can just fix HTML again. It’s more important that HTML caters to the present than to the future.

This is a lot easier to buy, especially as a lot of more extensible specifications have been sold before and failed on arrival. The best predictor of the future is still the past, and we have now 15 years of experience to build upon.

I use the code points 3008 and 3009,〈〉, to represent angle brackets to work around shortcomings in the blog software. The <hTmL> start tag thus looks like this:〈HTML〉