- From: Lachlan Hunt <lachlan.hunt@lachy.id.au>
- Date: Thu, 12 Mar 2009 12:35:38 +0100
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/
Received on Thursday, 12 March 2009 04:35:38 UTC