Andy Mabbett wrote:
> 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.
The time element was primarily designed to address use cases involving
contemporary dates. It doesn't address non-Gregorian calendars or BCE
dates by design, as it is not really meant for historical dates.
Probably the most historical dates that it would really be suitably
optimised for are people's birthdates, which, for people alive today,
don't really extend back beyond the early 20th century, with very few
exceptions.
The fact that it technically goes back to the year 0000 is only because
picking any other date would be completely arbitrary, and supporting it
requires no additional effort over supporting more recent years. Even
so, it still doesn't handle things like leap seconds, and nor does it
concern itself with the differences between the Julian and the proleptic
Gregorian calendars, especially for dates prior to the introduction of
the Gregorian calendar in 1582.
These issues have all been discussed before, either here in the whatwg
or on public-html, and so I won't go into great detail.
> 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.
I think this is a philosophical difference in approach from that which
we used in developing the time element, and other features in HTML5.
Semantics for the sake of semantics are not, and should not be, a design
goal. As you observed, hCalendar was designed to address the most
common use cases for marking up events, and so too was the time element.
This is the right approach since it allows us to design and optimise
features for the task at hand.
While it may seem like a logical step to go from supporting those real
use cases, to supporting theoretical cases involving BCE dates, Julian
calendars, leap seconds and whatever else, this actually only ends up
introducing unnecessary complexity.
> 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...
Yes, but the question is, are any of the use cases involving historical
dates really worth addressing with the time element? If so, what are
those use cases and why are they significant enough?
> 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.
What are the use cases for marking up such imprecise dates? Are people
using hCalendar for such purposes?
> 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>
Developing such a solution without having clear use cases and a good
explanation of why addressing those use cases is worthwhile, is not a
good use of our time. Even more so because you're trying to make room
for a hypothetical solution of marking up Julian dates that doesn't yet
exist.
> 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.
Until such a hypothetical standard for Julian dates becomes reality,
trying to find a solution to fit it into HTML5 is bound to fail.
> 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.
Because allowing them requires additional effort, such as changes to the
parsing requirements, for which there is little to nothing gained in
practice due to a lack of compelling use cases.
> 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>
I'm not familiar with the use cases for the geolocation microformat, nor
am I aware if there even are any. So I will not comment on this.
> 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>
What's the use case for this? Why would most people need to mark up
lunar co-ordinates? Are astronomers really asking for such facilities
to be included in HTML? Would we really be addressing their needs by
doing so?
> 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>
What's the use case?
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/