singer at apple.com
Wed Mar 11 10:22:38 PDT 2009
At 20:11 -0500 10/03/09, Robert J Burns wrote:
>>Indeed. That's one of the ways it can be done. IMHO it meets a huge
>>set of the possible use cases. And it has the sort of simplicity
>>that tends to be the defining characteristic of the best of HTML5.
>>(Well, parsing isn't simple and is clearly part of the best of, but
>>I am sure you get my drift...)
>Moving to a common calendaring system is important for comparing
>dates and perhaps searching for events in a uniform manner. However,
>it actually places a burden on authors to shoehorn dates into the
>Gregorian calendar and in terms of UTC when they would otherwise be
>expressed in some other calendar (or where UTC makes no sense
Well, not shoehorn: translate if they can.
<time datetime="...ISO 8601 string...">Hasan of the blacksheep being
Khan two years, in the month of the collection of walnuts, the third
day after the full moon</time>
-- the author worked out when this was (good for them).
Leave off the attribute, and you're saying it's a time and the author
could not (or did not) translate it.
I think this is what the draft says, to be honest. Get it from the
attribute if it's there, try to get it from the content, and if that
fails, the date is unknown.
The only possible downside with the current drafts are:
a) there is no attribute to say what the content format is. But
until someone comes up with a uniform descriptive set of tags for the
possible date formats, I'd leave this alone.
b) if the content is not a Gregorian proleptic date, and yet can be
parsed as such, and the datetime attribute is absent, then the user
may be misled.
I wonder why the 'try to parse the content' step is in there?
Multimedia Standards, Apple Inc.
More information about the whatwg