[whatwg] Dates and coordinates in HTML5

[Andy Mabbett]

This is a copy of my blog post:

  <http://pigsonthewing.wordpress.com/2009/02/23/dates-and-coordinates-in-html5/>

  (aka <http://is.gd/kB3k> )

please feel free to comment here, or there.


I'm grateful to Bruce Lawson of Opera for alerting me to discussion of
the <time> element on this mailing list 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 the 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
forthcoming events on the West Midland Bird Club's diary pages:

  <http://www.westmidlandbirdclub.com/diary/>

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):

  <http://developer.yahoo.net/blog/archives/2009/01/yql_with_microformats.html>

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"

  <http://simile.mit.edu/timeline/>

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>

-- 
Andy Mabbett