I’m grateful to Bruce Lawson of Opera for alerting me to discussion of the <time> element on the HTML5 mailing list (where I’ve posted a copy of this blog post) and encouraging me participate; and indebted to him for the engaging discussions which have led me to the ideas expressed below. So please blame him if you don’t like what I have to say 😉

I’ve read up on what prior discussion I can find on that mailing list; but may have missed some. I’ll be happy to have anything I’ve overlooked pointed out to me.

I have considerable experience of marking up dates in microformats, both for forthcoming events on the West Midland Bird Club’s diary pages; and for historic events, on Wikipedia and Wikimedia Commons.

I’ve been a staunch and early critic of the accessibility problems caused by abusing the <abbr> element for things like machine-readable dates (as has Bruce). The HTML5 time element has the potential to resolve that problem, but only if it caters for all the cases in which microformats are — or could potentially be — used.

It seems to me that there are several outstanding, and overlapping, issues for <time> in HTML5, which include use-cases, imprecise dates, Gregorian vs. non-Gregorian dates and BCE (aka “BC“) dates. First, though, I should like to make the observation that, while hCalendar microformats are most commonly used to allow event details to be added to calendar apps, and that that use case drove their development, they should not be seen simply as a tool to that end. I see them, and hope that others do, as a way of adding semantic meaning to mark-up; and that’s how I view the “time” element, too. Once we indicate that the semantic meaning of a string of text is date, it’s up to other people to decide what they use that for — ”let a thousand flowers bloom”, as the adage goes.

Use-cases for machine-readable date mark-up are many: as well as the aforesaid calendar interactions, they can be used for sorting; for searching (“find me all the pages about events in 1923″ — recent developments in Yahoo’s YQL searching API (which now supports searching for microformats) have opened up a whole new set of possibilities, which is only just beginning to be explored). They can be mapped visually on a “SIMILE” or similar time-line. They can be translated into other languages more effectively than raw prose; they can be disambiguated (does “5/6/09” mean “5th June 2009” or “6th May 2009”?); and they can be presented in the user’s preferred format (I might want to see “5th June 2009”; you might see “June 5, 2009″ — such presentational preferences have generated arguments of little-endian proportions on Wikipedia).

hCalendar microformats are already used to mark up imprecise dates (“June 1977”; “2009”). ISO8601 already supports them. Why not HTML5? Though care needs to be taken, it’s even possible to mark up words like “today” with a precise date, if that’s generated real-time, server-side.

The issue of non-Gregorian (chiefly Julian) dates is a vexing one; and has already caused problems on Wikipedia. So far as I am aware, there is no ISO-, RFC- or similar standard for such dates, other than converting them to Gregorian dates. It is not the job of the HTML5 working group to solve this problem; but I think the group should recognise that at some point a solution must be forthcoming. One way to do so would be allow something like:

<time schema="[schema-name]" datetime="[value]">[date in plain text]</time>

where the schema defaults to ISO 8601 if not stated, and the whole element is treated as simply:

[date in plain text]

if the schema is unrecognised; thereby ensuring backwards compatibility. That way, if a hypothetical ISO- or other standard for Julian dates emerges in the future, authors may simply start to use it without any revision to HTML 5 being required.

As for BCE dates, they’re already allowed in ISO 8601 (since there was no year 0, the year 3 BCE is given as -0002 in ISO 8601). I see no reason why they should be disallowed in <time> elements in HTML5. We wouldn’t, to take an extreme example, say that “<P>” can be used for paragraphs in English but not French; or paragraphs about literature but not music, so why make an effectively arbitrary limit on the dates which can be marked up semantically? Surely the use case for marking-up a sortable table of Roman emperors, should allow all such emperors, and not just those who ruled from 0001AD, to be included?

Coordinates

Another abuse of ABBR in microformats for coordinates:

<abbr class="geo" title="52.548;-1.932">Great Barr</abbr>

Bruce and I agree that this could be resolved, and HTML5 usefully extended, by a “location” element:

<location latitude="52.548" longitude="-1.932">Great Barr</location>

Using the “schema” attribute shown above, for non-Gregorian dates, we can extend that for Martian, Lunar (and eventually other bodies):

<location schema="moon" latitude="52.548" longitude="23.47297">Sea of Tranquility</location>

and for nonWGS84 coordinates, in a manner similar to that I described in my proposals to extend the related Geo microformat.

Now all we need to do is to work-around the abuse of ABBR for durations, in the draft hAudio microformat:

<abbr title="PT3M23S">3 minutes 23 seconds</abbr>