HTML5 element <time> has been following the path of the hokey cokey of late, with its in/out nature regarding the HTML5 spec. First, HTML5 spec editor Ian Hickson booted the element, then devs complained and W3C restored it. When we reported on the latter, Hickson wasn't available for comment, but he's since kindly decided to answer our questions on the original backlash and the element's reinstatement.
Hickson dismissed complaints that he'd 'overstepped his bounds' (as claimed by W3C member Paul Cotton) as "just W3C bureaucracy – I tend to ignore it" and instead focussed on his thoughts about the <time> element, its removal, and its subsequent reprieve. "It turns out that actually most people aren't using the <time> element that was in the HTML specification. They're using something much more similar to what the <data> element provides, but with syntax specific to time-related concepts," he told us. "It looks like the previous spec did a very poor job of explaining to people what the element really was, and they assumed it did what they wanted instead!"
According to Hickson, the plan is now to add a <time> element that "matches what people actually want, to handle the use cases that people have brought up," which mostly relate to disambiguation of time-specific syntaxes versus other data syntaxes people might use with <data>. Going forward, Hickson expects other elements will be added, such as <geo>, or <scalar>, for other data syntaxes that are especially common and therefore can justify having a dedicated element rather than just using the generic <data>. "The <time> element that used to be in the spec does things like locale-specific rendering, which it turns out basically nobody wants," he added. "It also only supports a very limited set of syntaxes, far fewer than people actually wanted or even used, in some cases, and it provided an API that was of minimal practical use – all of which are reasons why <time> was replaced with <data> in the first place."