Ian Hickson, editor of the HTML5 specification, has decided to drop the proposed <time> element from HTML5. The loss of the time element means, among other things, that there will be no semantically meaningful way to specify publication dates in HTML5.

Hickson claims that the <time> element wasn’t being used for two of its primary use cases, namely easier CSS styling and to indicate publication dates for web documents. He goes on to argue that the third main use case for the time element — writing dates in a machine readable format — is better handled by the more generic <data> element.

However, Hickson’s claim that <time> “does not seem to have much traction” on the web isn’t borne out by the facts.

In fact support for the time element is already baked into the Opera web browser and it’s being used on popular sites like Reddit, the Boston Globe and in the default WordPress theme, to say nothing of the countless personal sites and blogs already using <time>. That’s more real-world support than many other HTML5 elements can boast (and those elements aren’t being cut from the HTML5 spec).

What makes the “it hasn’t caught on” argument even weaker is that HTML5 is not yet a finished spec, so claiming that no one is using the time element before officially endorsing the time element doesn’t make much sense. It’s a chicken and egg problem. For example, some Microformats could have been rewritten to use <time>, but the Microformats developers need the W3C to endorse HTML5 before they can suggest adding HTML5 elements like <time> to Microformats.

Opera’s Bruce Lawson has spoken out against dropping the <time> element, calling it “a bad decision,” and suggesting that the more generic <data> is less useful than <time>. Lawson defends <time>, writing:

(or its precursor, ) has an obvious semantic (easy to learn, easy to read). Because it’s restricted to dates and times, the datetime attribute has a specific syntax that can be checked by a validator. Conversely, has no such built-in syntax, as it’s for arbitrary lumps of data, so can’t be machine validated. This will lead to more erroneous dates being published. Therefore, the reliability and thus the utility of the information being communicated in machine-readable format diminishes.

Indeed Lawson is only one of a handful of prominent web developer’s questioning Hickson’s decision. Developer Tantek Celnik suggests a compromise, writing that HTML5 should “keep <time>, expand its granularity, drop pubdate, introduce <data> and study how it’s used.”

The question for many developers is, should we continue to use <time>? The answer is that it depends. Hickson does not have a history of bending to popular opinion, but there has been a great deal of outcry surrounding the loss of time. There’s a chance, despite having an official status of “resolved, fixed” on the HTML5 bug tracker, that <time> might be added back into the spec.

Unfortunately that chance seems slim at the moment. Going forward the more conservative plan would be to use a Microformat like hAtom (or some of the similar efforts from schema.org) in conjunction with the HTML5 data element to create markup that’s valid HTML5, but also retains the semantic meaning lost with the removal of the time element.

See Also: