The HTML 5 spec introduces the <time> element to mark up a date or time. Although I support the inclusion of these semantics in HTML, I believe that the current specification of the <time> element is vague because it avoids the question whether the element is safe for historians. Right now it hurts historical research more than it helps. In this entry I’ll explain why.
Although I will concentrate on the HTML5 syntax here, what I have to say also applies to the microformats datetime design pattern. The Microformats site adds one important detail to the discussion that the HTML5 spec overlooks: the point of having a <time> element (or a datetime design pattern) at all:
Use the datetime-design-pattern to make datetimes that are human readable also formally machine readable.
Who needs machine readable dates? As far as I can see there are two target audiences for this operation. The first is obviously social applications that have to work with dates, and where it can be useful to compare dates of two different events. An app must be able to see if two events fall on the same day and warn you if they do.
However, as a target audience social applications are immediately followed by historians (or historical, chronological applications). After all, historians are (dare I say it?) historically the most prolific users of dates, until they were upstaged by social applications.
This raises the question whether the <time> element should be tailored for historical use at all. When I started writing this entry I was convinced that it should.
In keeping with the definition of its purpose I the see the <time> element as a tool for an Internet-wide chronological search-and-compare system. Such a system will be a boon to historians, who would be allowed to quickly and easily look up events that happened around the same time as the event they’re writing about.
In history, just as in other academic disciplines, serendipitous discoveries are the meat of exciting new theories. A history-compliant use of the <time> element that allows automatic search and compare would broaden the horizons of historians.
However, now that I’ve reviewed some of the more common problems that have to be solved in order to decrease potential harm, I’m starting to doubt whether the <time> element can easily be made to fit history.
Right now, though, the specification is a vague compromise that doesn’t make the <time> element useful for historical research, but still allows it to be used historically.
I feel this ambiguity should be removed. I feel that the specification should clearly state whether the <time> element is meant for historical use or not. The current vague, implied “No” should be changed to a clear answer. I prefer Yes, but I can live with No.
If the <time> element should be made safe for historians, there’s quite a bit of work to be done; some of which is discussed in this article. If it should not be made history-safe, we have to add a cut-off date to the specification. Dates before this cut-off date would be ignored.