The return of <time>

If you’re interested in this stuff at all, you’ll probably know this, but for the sake of completeness, the <time> element has returned to HTML5 after it was removed from the specification.

I reserved cheering until in case it was grudgingly returned to the W3C spec but not the WHATWG spec, as I don’t particularly want to see forked specs.

The old version of the element is now in the W3C spec, but not in the WHATWG version. But I’m not worried; it appears that it will be added as a New!Improved! element with some extra features to make it actually useful that I’ve been asking for since March 2009.

Editor Ian Hickson wrote

A few weeks ago, I replaced <time> with <data>. We got feedback from many people saying that there were use cases that <data> didn’t handle, and requesting <time> be left in the spec. It turns out what people were asking for was not quite the old <time> element, it was more like a variant of <data> that was specifically for <time>. (The old <time> was specified as doing locale-specific rendering, had a more or less useless API, and only supported a small set of data and time syntaxes.) Tantek made a proposal for how to handle these use cases, which I intend to add to the spec ("the <time> element is dead, long live the <time> element").

Indeed. <time>2.0. Time, after time.

Hickson has also hinted that we might get a <geo> element, too (as I suggested in my HTML5 Semantics talk at Fronteers.)

(Let’s just hope Tantek doesn’t neglect the vital use-case of 4 simultaneous days in 24 hrs advocated by Gene Ray’s Timecube theory.)

2 Responses to “ The return of <time> ”