[whatwg] Expanding datetime

[Benjamin Hawkes-Lewis]

Ian Hickson wrote:
> On Thu, 24 Apr 2008, Henri Sivonen wrote:
>> How do proleptic Gregorian dates before the Common Era fit into any of 
>> the use cases that states are used for in HTML?
>>
>> Insertion and deletion dates are contemporary. Date form widgets are 
>> meant for airline and hotel reservations and, hence, need to pick dates 
>> from the near future. The time element is meant for microformats, which 
>> means that it will be used for encoding current or near-future events 
>> dates.
> 
> Right.

Wrong.

Microformats may also be used to mark up events that happened in the 
past and people who are dead. For example:

http://en.wikipedia.org/wiki/Walt_Disney

If HTML5 does not provide a way to specify datetimes BC, then the 
microformats community would be left in the boat they're already in of 
trying to fudge markup to encode datetimes BC. Little gained, really.

Regardless of what elements are added to HTML5, I believe HTML5 needs a 
simple extension point where microformats can insert machine-parsable 
equivalents and expansions of human friendly data. Data types are by no 
means limited to those already covered by the HTML5 proposals:

http://microformats.org/wiki/machine-data

XHTML2 provides such an extension point with the (confusingly named) 
CONTENT attribute:

http://www.w3.org/TR/xhtml2/mod-metaAttributes.html#adef_metaAttributes_content

Such an extension point could meet the use-case of making datetimes BC 
extractable and also any use-case for far-future datetimes without 
requiring HTML5 to explicit specify calendar APIs for them.

DATA-* is not yet such an extension point, since it is only to be used 
for private scripts not public metadata:

http://www.w3.org/html/wg/html5/#custom

Obviously, it would be /ideal/ if DATETIME could actually handle a range 
of dates useful for educational and research purposes as well as social 
networking and business and if schoolkids and academics didn't have to 
fall back on extension points and homebrew code, but I accept that it 
would inevitably be more work to spec and probably for user agent 
developers to ultimately implement.

--
Benjamin Hawkes-Lewis