David Singer wrote:
At 3:22 +0100 10/03/09, Charles McCathieNevile wrote:
The other issue is the one of precision - while you can name a single
year, which will deal with a lot of use cases there are a lot left out
because the precision required is a period. Ranges are included in
8601, and making a range syntax that handled almost all the relevant
use cases is pretty straightforward.
Adding a range construct to 8601, or having a range construct ourselves
using 2 8601 dates, seems like something we could ask for or do.
ISO 8601 already has a syntax for durations and time intervals [1].
However, until we consider allowing the syntax to be used in HTML5, we
still need to know the use cases and understand what problems would be
solved by using the time element. So far, we've had vague use cases
related to historians and time lines, and others relating to imprecise
event dates. But there's been no clear description of the problems that
need solving, nor any explanation of why they are significant enough to
be addressed.
I think the design principles that are applicable here include Solve
Real Problems [2], and the proposed Baby Steps [3] principle (which
still needs to be added to the design principles document).
I think baby steps is particularly relevant here because we really
shouldn't be attempting to solve every little problem. Yet that seems
to be what some people are pushing for by asking for alternative
calendar systems, better historical date support, durations and time
intervals, without much regard for the complexity such features would
introduce for both authors and implementers.
In regards to contemporary dates, which are already supported, the
problems solved by the time element include fixing the accessibility
issue with hCalendar's use of the <abbr> element, and problems regarding
ambiguity of regional date syntaxes.
e.g. the date 04/02/09 means different things to different people
depending on the conventions used in their country. By using the time
element <time datetime="2009-02-04">04/02/09</time>, the ambiguity can
be solved by allowing UAs to expose the date to the user in a less
ambiguous format. (Although, it would be better if people avoided such
ambiguous dates, that doesn't seem too likely to happen with most people).
Another potential problem solved is helping to distinguish arbitrary 4
digit numbers from years, so that screen readers can pronounce them
correctly. e.g. If 1983 is meant as just a number, it should be
pronounced as "one thousand nine hundred and eighty three". But if it's
meant as a year, then it's conventional to say "nineteen eighty three"
instead. Although, I'm not certain if this is a real problem or not, I
could be completely wrong about this. I've been told that screen
readers have settings for this and possibly some limited heuristics for
detecting if a given number is a year or not.
[1] http://en.wikipedia.org/wiki/ISO_8601#Durations
[2] http://dev.w3.org/html5/html-design-principles/#solve-real-problems
[3]
http://esw.w3.org/topic/HTML/DesignPrinciplesReview#head-98fea741b3ace0c8da87029864ec4a5db4b2358e
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
