[whatwg] <time>

[Lachlan Hunt]

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/