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 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.
The format is very simple:
<time>2009-11-13</time>
<!-- without @datetime content must be a valid date, time, or precise datetime -->
<time datetime="2009-11-13">13<sup>th</sup> November</time>
<!-- when using @datetime the content can be anything relevant -->
<time datetime="20:00">starting at 8pm</time>
<!-- time example -->
<time datetime="2009-11-13T20:00+00:00">8pm on my birthday</time>
<!-- datetime with time-zone example -->
<time datetime="2009-11-13T20:00Z">8pm on my birthday</time>
<!-- datetime with time-zone “Z” -->When using the datetime attribute you can have whatever you want between the tags.
Note that the last two examples show the use of a timezone offset, which is required for a date + time. Timezones range from -12:00 to +14:00. You can use “Z” to represent Coordinated Universal Time (UTC), which is the same as +00:00.
The fly in the ointment
The only trouble with <time> is that it must contain a 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).
Unfortunately 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.
For more on this problem refer to Oli’s comment below, and our article Extending HTML5 — Microformats.
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.
Note that with pubdate we must use a date or a precise datetime + timezone.
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. A Japanese browser could localise <time>16:00</time> to “16:00時”. 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.
Please note that since this was written, <time>, datetime have been made more powerful, and pubdate is (possibly) to be dropped. Doctor Bruce has the low-down in his blogpost The best of <time>s.
The time element (and microformats) originally appeared on HTML5 Doctor on February 9, 2010.