The time element (and microformats)

Microformats are a way of adding extra semantic information to a webpage using HTML classes — information like an event’s date and time, a person’s phone number, an organisation’s email address, etc.

They aren’t a “standard” per se, but they are a widely adopted convention within the geek community. And since they use an agreed-upon set of class names, they are as compatible with HTML5 as they are with HTML4 or XHTML.

HTML5 offers one potential addition to the microformats arsenal. Because earlier versions of some microformats presented accessibility problems in the way they encoded dates and times (see an article called hAccessibility that I co-wrote with James Craig), HTML5 offers a new element for unambiguously encoding dates and times for machines while still displaying them in a human-readable way.

The format is very simple: <time datetime="2009-11-13">13 November 2009</time>:

The time element represents either a time on a 24 hour clock, or a precise date in the proleptic Gregorian calendar, optionally with a time and a time-zone offset.

You can have whatever you want between the tags, so:

<time datetime="2009-11-13">13 November 2009</time>
<time datetime="2009-11-13">13<sup>th</sup> November</time>
<time datetime="2010-11-13">Bruce's 21st birthday</time>
<time datetime="2010-11-13T020:00Z">8PM on my birthday</time>
<time datetime="2010-11-13T020:00+09:00">8PM on my birthday—in Tokyo</time>

are all equally valid.

Note that the last example has an optional timezone offset (+09:00) too. (Thanks, Oli!)

The fly in the ointment

The only trouble with <time> is that the it must contain positive date on the Proleptic Gregorian calendar, meaning you can’t encode a date before the Christian Era. Neither can you encode imprecise dates such as “July 1904″. Microformats, however, aren’t subjected to this restriction and are often employed to mark up, for example, very old events on Wikipedia or imprecise dates on museum websites. It’s likely that authors will continue using the current, more flexible microformat patterns unless the restrictions on the <time> element are lifted. (The HTML5 working group has been continually petitioned to remove their arbitrary restrictions and widen the scope of time, but with no success).

Perhaps because of this restriction, current microformat clients can’t consume microformats such as hCalendar if they’re coded to use <time>. Stefan Schipor wrote to us saying, “The problem is that I need to parse the site with H2VX or any other similar thing for exporting. Sadly, H2VX doesn’t seem to read the datetime attribute in the <time> elements. Nor does the FF add-on Tails. I tried the microformats IRC channel and the microformateers twitter account but I didn’t get any response. Do you know if there is any support for this? It would kill me to add <abbr> elements just for it to work.”

Incorporating the pubdate attribute

This doesn’t mean that <time> is an a waste of time, or that it’s more trouble than it’s worth (a white element, as it were). It has a great deal of scope outside microformats, too.

On my personal blog, I use it to mark up publication dates of articles. There is a boolean attribute pubdate specifically for this:

<article>
  <header>
  <h1>My brilliant blogpost</h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm wearing sexy socks! Here's a picture.</p>
  ...
</article>

The spec says:

The pubdate attribute is a boolean attribute. If specified, it indicates that the date and time given by the element is the publication date and time of the nearest ancestor article element, or, if the element has no ancestor article element, of the document as a whole.

You might be wondering why the pubdate attribute is needed at all. Why not just assume that any <time> element in an <article>’s <header> is its publication date?

Consider this example:

<article>
  <header>
  <h1>Come to my party on <time datetime="2010-03-01">1 March</time></h1>
  <p>Published on <time datetime="2010-01-20" pubdate>20 January 2010</time> in the Sexysocks category.</p>
  </header>
  <p>I'm throwing a sexy socks party at Dr Naughty's Ladyboy Cabaret Roller-disco Bierkeller Pizza-parlour-a-gogo! Do come.</p>
  ...
</article>

You’ll see that there are two dates within the <header>: the date of the actual party and the publication date of the article. The pubdate attribute is required to remove any ambiguity.

Where could time be used?

The uses of unambiguous dates in web pages aren’t hard to imagine. A browser could offer to add events to a user’s calendar. A Thai-localised browser could offer to transform Gregorian dates into Thai Buddhist era dates. Content aggregators can produce visual timelines of events.

Search engines can produce smarter search results. For example, in the recent heavy snow in the UK, I searched for school closures in my town and discovered my kids’ school was closed. After receiving a phone call from the school asking me where my kids were, I re-examined the webpage. In small print at the bottom of the page were the words "Published 5 January 2008". I expect that operators of search engines would rank more current pages more highly on searches connected with current events.

Share and Save:
  • Twitter
  • Digg
  • Sphinn
  • Reddit
  • del.icio.us
  • StumbleUpon
  • Technorati
  • Netvibes
  • Facebook
  • Google Bookmarks
  • FriendFeed
  • HackerNews
  • LinkedIn
  • NewsVine
  • Tumblr

This article was written by Bruce Lawson. Bruce evangelises Open Web Standards for Opera. He's a member of the Web Standards Project's Accessibility Task Force and the W3C Mobile Best Practices Working Group. Previously, he was technical lead for the Solicitors Regulation Authority site. He's been a tarot card reader in Istanbul, a volunteer pharmacist in Calcutta, a Bollywood movie extra in Mumbai and English tutor to a Princess' daughter in Thailand. Nowadays, he blogs at www.brucelawson.co.uk, is training for his blue belt in kickboxing and drinks too much Guinness.

Posted on

Got anything to add or ask? then leave a response,
or trackback from your own site.

Categorised under: Accessibility, Attributes, Elements.

Tagged with: , , , .

19 Responses to “ The time element (and microformats) ”

Comment by Arnout Kazemier at

The time element is really simple to be used. I’m currently transforming my static resume in to HTML5 powered mini site. The only issue i ran in to and in my point of view the biggest downfall of the time element is that it doesn’t allow you to specify time or date ranges. You will need to create 2 separated time elements.

For example my resume has a work experiance sections that displays my previouse jobs with the dates ” Jun 2000 – Present

It would be more secematic if i could do <time datetime=”2000-06-20/2010-02-08″> Jun 2000 – Present </time>

instead of
<time datetime=”2000-06-20″> Jun 2000 </time> – <time datetime=”2010-02-08″> Present </time>

But thats just my 2 cents :) . Nice article though

Comment by Oli at

Spiffing article, old chap!

It’s a pity that current Microformats tools can’t access <time>, but it seems like it’ll be included in future Microformats specs, so I expect (well, hope) support will be forthcoming.

For the … foreign among us, if you need to add a timezone, add “+” followed by the offset in hours at the end. For Japan it’s 9 hours, or +09:00. A proper example is “<time datetime="2010-11-13T020:00+09:00">8PM on my birthday—in Tokyo</time>!”

Toodle pip!

Comment by Gonzo at

@Arnout Kazemier, I think that’s the idea of the <time> element – to specify exact moment in time. A time period is defined by the start and end times, so if you want to be semantic and precise, you should use two elements, like the hCalendar spec suggests.

In one of the first projects where I used hCalendar I tried to use <time> instead of <abbr> to address the accessibility issues, but I discovered that none of the microformats parsing tools and some of them did not allow <span title=”"> to be used either. I had to go back to the <abbr>.

At the end it is the way developers use HTML5 that matters, not what the standards bodies say. When faced with real time problems, we can twist the specs the way it suits our needs. So writing something like <time datetime=”1910-05-00″< or <time datetime=”350BC”> wont break the web or someone’s browser (hopefully).

Comment by Jeremy Keith at

The problem with the microformats tools that don’t parse the time element right now is that they use Tidy. Because Tidy has a whitelist of HTML elements it uses to “clean up” the mark it’s fed, any elements that are new to HTML5 will get stripped out.

This isn’t just a problem with the time element. If you want to put a microformat class name (such as “vcard” or “vevent”) onto a new HTML5 element like section or article, the same tools won’t be able to parse them.

If anybody has any experience of hacking Tidy (or knows of a more extensible alternative), you’re help would be much appreciated: http://microformats.org/wiki/h2vx#HTML5_support

Comment by Andy Mabbett at

A useful round-up Bruce, thank you.

The microformat model would render “pubdate” as, say, <time datetime=”2010-01-20″ class=”published”> (from the hAtom spec) in the same way as a start date: <time datetime=”2010-01-20″ class=”dtstart”> or birth-date: <time datetime=”2010-01-20″ class=”bday”> and so on.

Whether or not microformats can be used meaningfully for non-Greorian dats is a matter for debate, not least on Wikipedia. This might be resolved by the very interesting (I must get out more…) Extended Date Time Format efforts based at the USA’s Library of Congress; whose mailing list I would urge anyone intersted in this matter, to join.

Comment by Andy Mabbett at

P.S. I wholeheartedly support calls for broadening the specification of the <time> element in HTML5 to cover use-cases such as those described above. And I can spell “Gregorian”.

Comment by Aaron T. Grogg at

Nice timing, Bruce, am presenting on MFs at work tomorrow and this came in just in time to help boost my opinion!

And, seriously, is there such a thing as too much Guinness??

Cheers,
Atg

Comment by Bruce Lawson at

Jeremy – thanks for clarifying why microformat parsers and HTML5 don’t currently play nicely.

Aaron – it’s counter-intuitive, I agree, but my waistline is a testament that “too much Guinness” is a possibility,

Comment by Nathan Peretic at

Bruce,

It appears the pubdate attribute should not be used in a list of articles since no ancestor <article&rt; element is present. (Ex. an unordered list of headlines and publication dates each linking the the specified article.) If that is the correct reading of the spec, it seems counter-intuitive to me. Perhaps pubdate should not default to entire article in the absence of an article ancestor element. The question then is how to make the relationship between the article headline and the publication date, both of which, again, are enclosed in a single <a&rt;.

Comment by Nathan Peretic at

I wish I could edit the previous comment. Please excuse the entity typos. Also, the second to last sentence should read, “Perhaps pubdate should not default to the entire document in the absence of an article ancestor element.”

Comment by Bruce Lawson at

Hi Nathan, the answer is in a bit of the spec I didn’t quote. If you have a series of articles, each with its pubdate, heading and a link to the page with the full article is on, there is no problem. Each article has its own pubdate. An element can only have one pubdate-time child, otherwise it’s an error:

For each article element, there must no more than one time element with a pubdate attribute whose nearest ancestor is that article element. Furthermore, for each Document, there must be no more than one time element with a pubdate attribute that does not have an ancestor article element.

Comment by Nathan Peretic at

Thanks for the clarification, Bruce. I should have consulted the spec before asking.

We have been using HTML5 exclusively since August. HTML5 Doctor has been a valuable resource. Keep up the good work.

Comment by Aaron T. Grogg at

@bractus:

Perhaps not immediately, but there have been a few recent developments from Palo Alto that might make you want to look more deeply at Microformats:
http://googlewebmastercentral.blogspot.com/2009/05/introducing-rich-snippets.html
http://googlewebmastercentral.blogspot.com/2009/10/help-us-make-web-better-update-on-rich.html
http://googlecustomsearch.blogspot.com/2009/05/enabling-rich-snippets-in-custom-search.html

Although <time> is not explicitly addressed yet, I would be very surprised if it were not something they were already working on.

Atg

Comment by Oli at

An update on @Jeremy Keith’s comment—it seems that HTML5 support in Tidy won’t be forthcoming anytime soon, unless someone takes it on and submits a patch. Tidy doesn’t appear to be under … active development (ahem) really either. Another contender is html5lib, which is being actively developed, and has usable Ruby & Python versions. There’s a PHP version too, but it’s still 0.1.

I asked @Tantek about html5lib — he maintains the PHP-based H2VX service which allows you to auto-generate vcard and ical files for download from Microformats. He’s keen to use Microformats with HTML5 structural elements too. He’s prolly going to check out html5lib-php-0.1 sometime soon, and is also considering other methods that don’t rely on Tidy or html5lib (ie no validation so up to you to submit well-formed code). For me a lack of an HTML5-friendly service like H2VX is probably the biggest stumbling block atm.

The upshot is currently uF with new HTML5 elements may fail, but I expect they’ll work with end-user tools in the near to mid future. I also suspect (well, hope (again)) that search engines who currently process uF will support HTML5+uF more quickly.

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <b> <blockquote cite=""> <cite> <del datetime=""> <em> <i> <q cite=""> <strong>

You can also use <code>, and remember to use &lt; and &gt; for brackets.