HTML5 dumps TIME element

“It’s with great sadness that I inform you that the HTML5 <time> element has been dropped, and replaced by a more generic – and thus less useful – <data> element. The pubdate attribute has been dropped completely, so there is now no simple way to indicate the publication date of a work.”

Much more at Bruce Lawson’s personal site. Hat tip: Stuntbox.

33 thoughts on “HTML5 dumps TIME element

  1. Any insight you might be able share? What was the thought process behind removing something that made sense and was useful? (How often do those two attributes collide?)

  2. This is hubris run amuck and I am not being hyperbolic. Is not one of the goals of HTML5 to build a semantic language? Tell me how removing one of the most critical semantic tags in the spec forwards that goal.


    (NOW I’m being hyperbolic.)

  3. What? WHAT?! (I am wearing a crow costume as I freak out about this to my coworkers, FYI. Black feathers flying.) data is not semantic! It doesn’t mean anything! It’s only a few steps above span or div! This is not going to improve HTML markup’s human readability. I’ve always felt HTML should make sense to humans eyes as well as machine parsers.

    I will politely dissent by continuing to use the time tag since I have already put so much time into including it in so many themes and designs.

    This is even worse than when dialog was cancelled. I’m going to sulk and gorge on Halloween candy now.

  4. I’m actually not terrible disappointed in this. In a lot of ways, I feel like HTML5 was starting to reach a bit beyond the scope of what I think is appropriate for a markup syntax. Time data is far more appropriate as metadata, stored in parallel to the content being presented – not necessarily structured data marked up in the base page file. By including it as markup, you have to put an inherent trust in the coder to keep the syntax appropriate. Instead, you now defer it to something like a microformat, where it’s way more appropriate IMO. As something like an SEO tool, there are too many ways to (mis)use and abuse it, which really limits it’s actual usage beyond that point.

  5. For a few years now ‘edgy’ web developers have quietly (and not so quietly) dissed the way that W3C establishes Standards and Specifications, and have have run, blindly, to the WHATWG version of the HTML5 version of the specification – it’s more up to date, it’s what the browsers are doing today, ignore the gray-beards, yada, yada, yada.

    Now you have a clear-cut example to understand why this particular strategy can have negative consequences. Yes, W3C moves a bit slower, but that’s because they *do* allow discussion, dissent, and works on a consensus based methodology, as opposed to the autocratic “what Ian Hickson says goes” (anti)process at the WHATWG.

    You want #occupyhtml5 to be a real thing? Stop propping up the WHATWG’s pseudo-legitimacy and get behind the democratic W3C process. Blog authors and other writers: when talking about the HTML5 specification (and pointing to a URL), point to the W3C version instead. Never forget that the funders and behind-the-scenes supporters of WHATWG are Apple, Mozilla, Opera and Google. That’s it, anyone else is just noise that Hixie can and usually does ignore, at his whim, and to date many just sort of tolerate that. Now you know why *I* don’t.

    #occupyhtml5 needs to be more than just a slogan – get behind the ideal with actions.

  6. I find this to be a step back. The time tag could have been useful, because it reads like natural language. The data tag sounds more like a machine one. Maybe it’s used for statistics? I don’t know. On the internet, everything is data. And because there are many ways in which the data tag can be used, you’ll need to add more meaning to it in the form of attributes. This was what HTML5 was initially trying to avoid – for instance by making a div tag with an attribute value of “header” just a header tag. Maybe we should then avoid using the address, figure and other tags after all, because they are data too and may not survive? I can’t see how this is helping the whole HTML5 specification “gain more traction”.

  7. Ridiculous. The amount of blogs online alone justify the use and existence of a element. Let’s factor in the massive amount of documentation online via Government websites that would benefit from a semantic and agreed upon timestamp format.

    Can we just keep using it anyway and hope that the powers that be see the errors in their way through passive protest?


  8. I agree, this is ridiculous. I’ve been using along with microformats for a while now and it addresses a large number of specific needs in terms of semantics. The element is simply too generic and seems to be akin to using for all text-based formatting instead of using something specific like or .

    Jeffrey’s right about the #occupyhtml5 hashtag being hot right now. Something definitely needs to change with this process…

  9. Dear “godfather of the web”,

    Can you use your relationships to provide us a way to rally the community in support of <time> and the pubdate attribute?! Is there a petition to sign?

    This element was one of the most logical and obvious additions to HTML5 from my perspective. I’ve rolled it into at least a half-dozen new sites in the past year and retrofitted existing sites as the opportunity has presented itself. I realize this was part of the draft spec (or whatever classification), but it was so sensible it seemed low-risk to begin implementing.

  10. There is little of more value to assessing “the worth of information” than knowing its context in time – fundamentals of data becoming ‘information’ are who authored the work, *when* and where.

    This move is a little disappointing. I expect the rationale from [he who must not be named] would just confirm what drove me away from web development in the last few years.

  11. @ Rian,
    Jeffrey Zeldman, influential as he is, is not an active participant in the HTML standardization process. The removal of the time element from HTML5 is not a foregone conclusion, in fact I believe it will be back in the W3C HTML5 specification within the week. This will occur because the editor of the HTML5 specification has acted in a manner contrary to the HTML standardization process in place at the W3C,this occurs because he does not respect the process. The relationship between the HTML5 editor (who has his own self styled organization – the WHAT WG) and the W3C is uneasy and fractious at the best of times. Thankfully we do have a process in place (the W3C HTML working group) that amongst other things serves to curb the behaviour of the editor, but sometimes it is tested (now for example). Good arguments have been put forward for not dropping time and good sense will prevail. The first part of the response to the dropping of time has occured: A revert request has been submitted to the HTML working group. This will be resolved in short order, not without cost to, those like myself who are actively involved in the process and have to mop up the mess and to those in the wider development community who advocate for the adoption of HTML5.

  12. I’ve been wanting to say for a while now… to all the people I happen to know who jumped head-first into HTML5 for production sites… “How does writing full HTML5 sites TODAY not feel like a game of Jenga to you??”

    <georgetakei<Oh My!</georgetakei>

    Hgroup, time… all those folks who started using WebSQL on production sites… step back. Back and forth? We’re the code monkeys in the middle. Catch!

    We don’t drive around in prototype cars, unless we’re testing them. Sure, we should be testing and using HTML5… but on production sites we earn money on?
    With an unfinished spec (no, wait, TWO unfinished specs that DIFFER), why is WordPress incorporating it now? Why is Drupal incorporating it now? Why are we writing this stuff for our paying clients now (and how is that possibly fair to them??)? Are we willing to drop everything on a dime and go back and quick change what we’ve coded last month so that it now follows the now-spec?? Is WordPress?

    Question: should that be an argument for making a change (or not) to an unfinished spec (“lots of blogs started using it yesterday!!”)? (I agree with the sentiment expressed earlier that many sites have shown a *need* for such an element, or attibute, or something)

    I don’t understand why people keep telling me “HTML5 is mostly stable” ’cause funny, that’s not what I’ve been seeing lately, and sometimes I like to think I know what is a stable tag/attribute and what isn’t, but no.

    Or does everyone else think this will be the last time something like this happens?

    I feel like the lone party pooper here, but this <time> thing kinda finally sets me off. Not because I was happy that it was totally useless for many historical times (maybe it should have been called <modernblogtime> instead? or fixed to work with more times?) but because the spec being worked on sometimes feels like it’s changed on a whim and maybe tomorrow someone will get up on the other side of the bed and we’ll suddenly have <cheezburger> tags or something. Who knows? Would be awesome though wouldn’t it?

    And I seem to get this feeling of peer pressure that I should act and work as if HTML5 isn’t going through all this. Am I wrong?

  13. Dropping is a mistake.

    If the HTML5 specification had tags for the publishing system used or any other ephemeral data and it was proposed to drop these, the arguments against dropping them would be weakened by their built-in obsolescence.

    Time does not suffer from that obsolescence — time is special to the human experience.

    Sure the in an HTML page is ‘just’ data, but it’s unique meaning to humans and computer systems, retrieval systems, archiving systems makes it uniquely important.

    Making time something that is established on a page via will not give time information the import it merits and will also I think ensure the publication, adoption and use of time information will be reduced and slowed.

    is not _just_ .

  14. Is this because of political correctness? Why should a higher importance be placed on lunar calendars than accessibility? #OccupyHTML5 indeed.

  15. HTNL 5 is less than effective for solving semantic issues. It is do to the fact that HTML semantics is on a sliding scale relative to native human semantics and the context it serves in time. You can’t teach nor regulate semantics. They removed pubDate because it is a non-starter to most people.
    Introduced in RSS it never took off.

    Just use HTML and figure out how to be more semantic to the end user and deliver useful product. That is the only semantics that matter.

  16. What? Why?!

    This is beyond idiotic. Time is a fundamental datatype common to everything.


    Javascript? Java? Python? Ruby? Hell, even XML has a standard for time!

    What backwards-minded fools thought this was a good idea? And for what backward-minded foolish reasons?!

  17. data? data?

    Wow, that’s just so non-semantic, it’s just silly.

    *everything* thrown at a screen is data.

    I think I’m going to completely ignore this decision and continue to use time – I feel certain everyone else will too – I’m just wicked and bad like that.

Comments are closed.