Goodbye HTML5 <time>, hello <data>!

This post is obsolete. See The return of <time> for the latest information.

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.

Editor Ian “Hixie” Hickson explained:

There are several use cases for <time>:

A. Easier styling of dates and times from CSS.

A way to mark up the publication date/time for an article (e.g. for
conversion to Atom).

C. A way to mark up machine-readable times and dates for use in Microformats or

Use cases A and B do not seem to have much traction.

Use case C applies to more than just dates, and the lack of solution for stuff
outside dates and times is being problematic to many communities.

Proposal: we dump use cases A and B, and pivot <time> on use case C, changing
it to <data> and making it like the <abbr> for machine-readable data, primarily
for use by Microformats and HTML’s microdata feature.

I think this is a bad decision.

<time> was originally dreamed up to correct an accessibility problem with microformats that James Craig and I raised in 2007.

While Hixie says it hasn’t had much traction in microformats. Ben Ward, a platform developer at Twitter and microformats admin, says “We’ve had time documented on the wiki HTML5 page for ages, some parsers had experimental support. But <time> wouldn’t be able to progress into being a requirement or even recommendation for Microformats until HTML5 had that status”.

It’s also used on and (with Alexa rankings of 112 and 549, respectively – hat-tip, Mike Taylor), the Boston Globe and default WordPress theme, twentyeleven (which has a mere 2.6 million installs). It’s also used in the Atlassian suite of products: JIRA, Confluence, Bamboo and BitBucket (hat-tip Ben Buchanan). Drupal developers have been adding it to the core theming systems, too.

<time> (or its precursor, <date>) 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, <data value=”"> 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.

The <data> spec says “A script loaded by the page (and thus privy to the page’s internal convention of marking up dates and times using the data element) could scan through the page and look at all the data elements therein to create an index of dates and times.”

This is a retrograde step from the <time> element that uses a wider standard/ convention for dates, such as ISO8601 because now the script must be “privy to the page’s internal convention”.

<data> as an element is for public consumption, eg for crawlers, search engines, microformats/ microdata parsers. Convesely, data-* attributes are private (only for scripts on a page, not external crawlers: “These attributes are not intended for use by software that is independent of the site that uses the attributes.” ). This is highly confusing.

I’ve added these points to a collaborative notepad set up by Eric Eggert, at his request.

But I have little hope that <time> and pubdate will be restored, even though most comments on the bug in which Hixie changed the spec were negative.

But sing along with me in my Cher costume, and we might just change Hixie’s mind.

Added 20:06 Oct 30: The Mighty Steve Faulkner filed a revert request.

Usual disclaimer: personal opinion, written on Sunday night, not Opera, etc etc.

Other discussion

Update 4 November 2011

At an HTML Working Groupp meet last night, it was decided to re-instate <time> and even extend it to encompass things I complained in 2009 were lacking — “fuzzy dates” like “1965″ or “February 2008″ and durations.

However, it remains to be seen whether it’ll be reinstated in both the W3C spec and the WHATWG versions or just the W3C. So I’ll delay celebration until then.

115 Responses to “ Goodbye HTML5 <time>, hello <data>! ”

Comment by steve faulkner

Hi bruce, I a little flummoxed by this statement
“But I have little hope that and pubdate will be restored, even though most comments on the bug in which Hixie changed the spec were negative.”

There appear to be good arguments as to why it should not be dropped. Does nobody who disagrees to the dropping of <time> from HTML5 have the will to get it restored, so it then can be debated, discussued and decided on a level playing field, have the intestinal fortitude to stand up to Hixie? So what if <data> replaces it in Hixies HTML at least the fate of <time> in everybody elses HTML5 will not be decided by the tapping of a few keys by Hixie.

Comment by Bruce

Steve, been doing lots of travelling and it’s taken it out of me, so I’ve run out of steam with the weird quasi-processes. Might have more gumption after a few days’ rest.

Other, less lily-livered people are welcome to invite the WHATWG pile-on. I’ll be cheering from the sidelines.

Comment by Ian Devlin

How does one go about getting it restored? I’ve been following the original thread about replacing <time> and to me it seemed that most comments were against the change. But it happened anyway. How does one go about fighting this?

Comment by Devon Young

When I saw this on Twitter yesterday, I imediately thought it was a joke… but then I realized we’re not anywhere near April 1st.

I can’t believe this is a serious decision and I can’t believe the reasoning for it. I mean after all — blogs & news article’s are not going the way of the dinosaur, so how could the time element have little use in the future? I bet it has opportunity for more use than the data element. The data element will probably be used 90% of the time by non-novice’s, whereas the time element would be used by expert’s, amateurs, and novice’s alike….on every blog, every news article, and used BY EVERY SEARCH ENGNIE.

the data element actually remidns me of some of the ridiculousness of the XHTML 2 spec, which is exactly why others decided to start creating HTML5…

Comment by Stephanie (Sullivan) Rewis

I have been pretty frustrated by this change. In fact, when I read the entire thread on the debacle, it nearly made me want to give up on teaching, and using HTML5. What’s the point when there’s really no discussion? A single person brings something up. Great arguments are made. And then he just does what he originally wanted to do anyway. So why discuss it at all? Seems the decision was already made.

I’m frustrated because I’ve been teaching people that semantics matter. Yet Hixie states otherwise in the thread. I’ve been teaching people that we have new elements because of their more specific semantics—which he just removed, making them more generic. I’ve been using the time element myself—I’m wondering how this element could “have traction” yet when there are many people waiting to use new HTML5 elements at all… because “it’s not done yet”… I guess Hixie just gave them confirmation, didn’t he? I expect they’ll wait even longer now—because the clients I code for aren’t going to pay me to go back into sites and change all the time elements to data elements. (And any other arbitrary changes he decides to change on a whim—no matter what other people want.)

I understand your lack of hope, but I would love it if someone in the W3C process would reopen the bug, like it says in his final note, so that the whole group can discuss it. Or has everyone just given up and Hixie is now a complete dictator?

Maybe I should just go back to using divs and spans… [disgust]

Comment by Rich Boakes

That’s a shame. Dates are intrinsic to documents, and as children, we learn to put the date on everything we write. Their inclusion helps with the document’s interpretation, giving context. For teaching markup, one part of HTML5 is a gift: the semantic tags. We now have ways of describing the structure of a complete document, and therefore as part of a logical introduction having a time element that isn’t reliant on attributes makes sense because it lowers the bar for beginners to create useful, meaningful, complete markup of documents. It is/was a much appreciated nicety.

Comment by David Turner

When I saw this change, I thought it was a joke at first, something that has already been replaced, I thought it was a joke. Then I read that it wasn’t and I got just a little angry, swiftly followed by disappointed.

Elements like <time> add a lot to sites. Abstracting them to be less semantic takes much more away than it adds. As you yourself have stated it renders the elements useless, as they don’t have any structure.

Hopefully common sense will prevail, and the much more semantic and useful <time> element will be restored to the HTML5 spec.

Comment by André Luís

I’m also a bit confused with this move. I have also been using for my projects and it was a very welcome addition to avoid coliding with the title attribute, which caused accessibility issues.

I’ve added one point to the etherpad (in pink). Hope it’s useful in trying to bring back.

Comment by Mark Sinkinson

I’m another who has been using the time element in my code a large part of this year. It’s in a large number of websites I have released and, along with the pubdate attribute, makes perfect semantic sense.

Removing the element and replacing with the data element seems like a step backwards. Data makes less sense to those inexperienced and is less likely to be used. I am a little confused as to why the change needed to be made.

Comment by Kean

It would be nice to think that the community at large could help in reversing a decision like this. I like many have been using HTML5 markup in a range of sites now and although I understood the spec was far from finished I had some confidence in using such tags like as they simply make sense. To now find that so many sites I’ve built would need to be changed to remain HTML5 compliant makes me question if I jumped on the bandwagon too early.

Comment by fvsch

A good solution: keep &lt;data&gt;, restore &lt;time&gt;.

Let me explain; &lt;data&gt; represents a pairing mechanism that afaik doesn’t exist in HTML. It pairs some visible data (the text content of the element) with some invisible data that is supposed to be a machine-readable representation of the visible data. This is not much, it has basically no semantics (it doesn’t say anything about the nature of the text content and related value), but it’s a simple syntactic construct that didn’t exist before in a generic, semantically-neutral fashion.

So you can use &lt;data&gt; for your own scripting needs, in the same way you would use a data-attribute but with a more precise syntactic value of “A represents B”. Then of course &lt;data&gt; is useful for mechanisms that extend the semantics of HTML (microformats, microdata, not sure if RDFa already has options for this), and solves a problem with those mechanisms. We should keep &lt;data&gt; around.

If &lt;data&gt; stays, then &lt;time&gt; becomes a special kind of data element, which adds a semantic meaning to the content (text content and machine-readable value), rules for the encoding of the machine-readable value, and possibly additional features (like the pubdate attribute). It might be a good idea to align the syntax of &lt;time&gt; and use a value attribute instead of datetime, for the sake of naming consistency.

And I wouldn’t lament the loss of the pubdate attribute since parsing an &lt;article&gt;’s content for &lt;time&gt; elements (prioritizing &lt;header&gt; or &lt;footer&gt; content if needed) would do the trick for finding the probable publication date of an article — and if authors want to provide very reliable info, they can use a microformat or microdata vocabulary.

Now, why have a &lt;time&gt; element and not semantic elements for 5 or 10 or 15 other types of data that require a “A represents B” construct? Well, we use dates at least one order of magnitude more than some of those other data types. And then there are data types that we use a lot in text, but we tend NOT to highlight them or extract them from an article to show them prominently as valuable information. On the other hand, we do mentally parse a web page to find when an article was published, and we appreciate search engines showing publication dates for results in their result pages.

Comment by Jack Lawson

This is very disappointing. I, like a lot of the others here, saw it on twitter and assumed it was just a discussion, not a serious proposal for changing. I use the time element pretty frequently (blogs, comments, and other user-posted materials.) Data has absolutely no semantic meaning. How is data any different than using a div? Machines know to look out for “data”, even though it has no meaning attached? Is this not a regression from the core goals of html5?

Comment by Aaron Gustafson

Seriously?! Honestly, this is one of the problems with having a single person in charge of the spec. I suppose it’s possible the W3C could keep it even if WhatWG drops it… I for one hope they do.

Comment by David

Oh that’s just great. I have fought hard in my organisation to get people to start using html5. Just, *just* when I was starting to get some traction, this happens. So now I’m going to be back to square one with the “you can’t use any of it until it’s a finalised spec in 2022″ brigade. I anticipate this may do some damage to the case of people like me who are fighting for html5 against the inertia and proprietary-framework-insanity of corporate organisations. Really quite cross.

Comment by Michael

Oh. Well, I guess this just demonstrates a point I’ve been trying to get across to people. Don’t use HTML5. Well, it’s a bit more complicated than that. It’s more, don’t use it on any site except your own personal site, because it’s still subject to change.

All you people who are using ‘time’ on websites that you’ve been hired to build, well… I would say it is unprofessional. Unless you’re continuing to support them, and will make the changes required to fix them to the new “standard” without extra charge.

Comment by Tantek

I understand both the frustrations and desire to simplify HTML5 (fewer elements = simpler).

That being said, here are my recommendations based on on experience:

tl;dr: keep <time>, expand its granularity, drop pubdate, introduce <data> and study how it’s used.


1. Keep <time>. It’s useful (per microformats uses, publishing examples as stated above, implemented in open source X2V, live in (considering flipping that to producing
2. and expand <time> to provide additional granularity per rough consensus proposals at

3. Drop pubdate. It was a vestigial feature left-over from an attempt to shoehorn partial hAtom-like functionality. In practice consuming sites use hAtom (e.g. publishers guidelines).

4. Introduce <data> and watch/collect/study stats on specific semantic publishing uses (measures, currency, time ranges, opening hours etc.) and consider adding more elements when there are statistically significant specific semantic uses for which a specific element would help with user-scenario/browser/consuming functionality, define a new element.

Comment by Stephanie (Sullivan) Rewis

I concur with Tantek’s notes above (in case I can’t leave a note anywhere else since I travel to Chile in the morning). I have no problem with the addition of data – there are some good uses for it, but TURN BACK TIME! ;)

Comment by Devon Young

I like Tantek’s idea.

And for now, if we all just keep using the time element anyway, it’ll kind of force the spec to include it again. After all, last I knew, HTML5 strives to be as close as possible to what developers are actually using. That’s why there’s a header element and a footer element, etc.

So I’m just going to keep using time, and make sure the rest of my document conforms.

Comment by bruce

Yup, tantek.

I don’t have any arguments with the addition of <data> except that it replaces rather than supplements time.

I like pubdate. (I’d like an extension that displays pubdates on articles, as I’ve twice been bitten by undated news items I’ve found and assumed they were current.)

Comment by Daria D.

pubdate was my reason to use time.

Telling robots when text in an article or body was published. Seemed so easy and straight forward to me.

Comment by Shelley

I have to disagree with Tantek on the introduction of data.

All changes to HTML5 supposedly come about based on the strength of use cases introduced. None that seem to have any viability have been introduced for data, while several have been introduced for keeping time. And time has actual usage.

We don’t need to bloat HTML5 with elements that are added and use cases gathered afterwards.

Comment by Aaron Gustafson

I agree with Tantek on this one. I do see Shelley’s point, but I view data as a span-equivalent for machine-focused content exposure.

Also, FWIW, I do plan to continue using time. Damn the torpedoes.

Comment by Philip Jägenstedt

Is there any consuming software that does anything with <time> currently? Just knowing that something is a date/time is hardly useful, so I guess the question is if any software does something with <time pubdate>.

Comment by Bruce

Philip – see Ben Ward: “Lack of uptake seems questionable? We’ve had time documented on the wiki HTML5 page for ages, some parsers had experimental support.”!/BenWard/status/130592844024004608

As far as I know, no software uses microdata (except for, which also uses time). Should microdata be dropped as well?

The ‘currentness’ of an article or news item is possibly the most important thing about it (after accuracy). time gave us a mechanism to easily and unambiguously associate that information with the content. Rich Boakes’ comment makes that point far better than I can.

If we can markup this information, it’s possible for the software to interrogate it and mash it up (just like microdata, but in a simpler way). If the mechanism to mark it up isn’t present, the possibility for machines to consume the information without silly heuristics diminishes.

It’s way too early to dismiss anything as not having sufficient traction—most corporate web developers are only just starting to look at HTML5 now.

Comment by steve faulkner

The revert request I posted has been supported by 2 (@ezufelt and @yatil) other W3C HTML WG members. Given the circumstances in which the change was made (Refer to Enhanced change control after the Last Call cutoff for details of when and why a change to HTML5 made by the editor can be reverted) and the considerable arguments for the continued inclusion of the time element in HTML5 I feel confident it will be back in the W3C HTML5 specification by the end of the week. Whether @hixie decides to put it back into WHATWG HTML is another matter.

Comment by Jim Peel

Re: comment 32, I couldn’t agreee more. We have just launched a very article-heavy, community driven museum website. The element gave us exactly that method “to easily and unambiguously associate that information with the content.”

Seems far too early in the lifecycle to be dropping it. We need more specific elements like to support these underlying mechanisms, not less.

Comment by Philip Jägenstedt

Is there any “software to interrogate it and mash it up” in use today?

If no browser except Opera implements microdata and no one actually does anything with it (approximately the status of <time>) then yes, I think we should drop it as well. Let’s check back in 3 years when microdata is as old as <time> is now.

Comment by zcorpan

Because it’s restricted to dates and times, the datetime attribute has a specific syntax that can be checked by a validator. Conversely, <data value=””> has no such built-in syntax, as it’s for arbitrary lumps of data, so can’t be machine validated.

It can be machine validated. But it moves from the HTML layer validation to the microdata vocab layer validation.

Comment by Bruce

The data spec says “A script loaded by the page (and thus privy to the page’s internal convention of marking up dates and times using the data element) could scan through the page and look at all the data elements therein to create an index of dates and times”.

From this I read that there is no single time format we can all use and share, but every validator and script must be privy to internal conventions.

For such a common usecase – a date – that has such a commonly-understood format like YYYY-MM-DD, it seems to me (and most commentators I’ve read) to be ridiculous to abandon that and go for a Babel of conventions, requiring 3rd party vocabularies to validate against.

Comment by Dylan Smith

I concur with the revert request.

In the news business, the time/date of publication is one of the most important aspects. Removing an element dedicated to that piece of information, and replacing it with one that has no specific, defined role, doesn’t strike me as a good move.

IMHO, both time and pubdate should remain in the spec.

Comment by Marko Samastur

@Philip It’s a bit early to measure current use although I bet it is more widespread than a lot of other features. Until there are enough sources using time there is little reason to develop processors for consuming them.

Personally I fail to see how <address> is more useful than <time>.

Comment by Samuel

wtf :( time was one of the best semantic tags there were in the HTML5 spec. Disappointed and a bit confused right now.

Comment by Mark Jaquith

Adding some data to the conversation.

I took a look at our internal stats. Approximately 4.103% of WordPress sites are using the Twenty Eleven theme, which translates to over 2.6 million WordPress sites using the &lt;time&gt; element.

Comment by Tantek

Philip asked:

Is there any consuming software that does anything with <time> currently? is a service that consumes <time> as used with the hCard and hCalendar microformats, e.g.

The support for <time> (and other HTML5 semantic elements) has been there for over a year:

It’s been well tested enough at this point that I’m likely going to flip the switch and push the <time> support to (unless I hear any objections).

Comment by Liz Guy

Hell no! I’ve just taught first year students to mark up their learning journal posts with <time> and pubdate. Unlike <data> it’s intuitive and easy to explain.

Comment by BARTdG

This is a stupendously bad idea. Dropping an element in favour of a new, more generic element, which by definition is less semantic.

This move won’t stop me using time. I don’t care about getting a validation stamp on my site. time means something, is being used elsewhere on the web and if enough people will continue using it, search engines et al will definitely use it in some way.

Comment by Tokimon

Such a shame.
I can’t really see why “data” should replace “time”. As everybody is saying “time” is way more semantic and easier to explain. I really can’t see why the two can’t coexists.

Comment by Ben Buchanan

TIME was useful, simple and solved a problem. DATA at the very least needs a type=”" attribute, so you don’t have to rely on “[scripts being] privy to the page’s internal convention” for even the simplest use case. I’d be ok with DATA being added to the spec (with a type attribute) but I see no reason to kill off TIME.

Comment by Douglas Greenshields

Slightly aside topic, but how do the data-* attributes being theoretically private square with the specs which expect them to be public (or are the specs verboten in these here parts)?

Comment by fvsch

@Douglas Greenshields: microdata doesn’t use data-attributes. I don’t remember seing data-attributes in the docs (just used Ctrl+F in every doc page I could find on, not data-* attribute used).

Comment by Anders Hellerup Madsen

How did it ever get this far? I mean, any argument for turning time into data could just as easily be used as an argument for removing all the new semantic HTML5 tags. I mean, why use article and nav tags, when a div or a span would work just as well?

As others have mentioned, the data tag seems to be rather pointless. It is completely equivalent to using a data-value property on a span tag.

The timetag (and the datetime and pubdate attributes) was a great addition to HTML5, and I sincerely hope sanity will prevail and this terrible change will be reverted.

Comment by Julio Loayza

As every piece of information is data, why don’t we just drop ALL the elements to leave just data?

HTML reduced to the simplest (best?) solution! Ta-da! :rolleyes:

Comment by Ben Buchanan

Back in the office today and FWIW confirmed several use cases across the Atlassian suite of products: the TIME element is used in production versions of JIRA, Confluence, Bamboo and BitBucket (view source any change history on BitBucket for an example).

Strangely enough, it’s used exactly as you’d imagine: providing a friendly format date to humans and a machine-readable timestamp for the machines. The TIME element is really useful.

Comment by widyakumara


will they also drop <header>, <footer>, <aside>, <nav>, <article>, <section>, etc and replace them with <div class=”header|footer|etc”>?

cos that would be awesome/s

Comment by Francesco

Of course I (like pretty much everyone else in the world) love the time element and have been using it for years, now. I hope this decision will be reverted.

But I find the “I was right in not using HTML5″ a bit funny. Pages that use the time element will not magically stop working, browsers don’t really care. It’s frustrating, I know (I LOVE the time element, have I already said that?), but that’s not a reason not to use HTML5.

Comment by Mark A

I never used <TIME> as it seamed pointless.
It was just a fixed string and not Javascript code that could display the current time,
or the date and time the page was last modified.

If I wonted to add the date and time to a page and hide them, then there seems no difference between using
<TIME> or <!– .. –>

Use the following will work with all version of HTML, not just HTML5
and search engines should also find it if they still read META tags.

<META NAME=”TimeDateStamp” CONTENT=”28/02/2011″>

Where NAME= could be any name and CONTENT= could be any string.

Comment by ben

What will th^^he think of next?


(Since the spec’s being messed with, why don’t they add that to the spec while they’re at it? Goodness knows the Internet could use it.)

Comment by Niels Matthijs

pubdate should be there for search engines too. It’s a necessity to guarantee better search results … data is way to generic, especially as a tag name (how generic can it get).

Comment by D

Hi strangers

I think they want everyone to work slower and confuse the hell out of artists so we need to hire programmers.

Here’s a lightbulb for ya:

Everyone who has replied to this… make it your new regimen to email this Hixie douche 5 times a day. Call him if you can get a hold of his work or the company’s main number. If he blocks your email and stops answering the phone, start sending regular letters and restart the whole cycle with his superiors and colleagues if you can find their addresses. I’d Cc all them from the jump.

Tell everyone else you know, email blast your whole address book, post articles on all your sites (and make sure to use multiple languages), and just get everyone in such a frenzy that they’ll have no choice but to put the tags back in for fear of be skinned alive.