[whatwg] <time>

Bruce Lawson wrote:
> On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt 
> <lachlan.hunt at lachy.id.au> wrote:
> 
>> I think the design principles that are applicable here include Solve 
>> Real Problems [2],
> 
> Real problems to be solved:
> 
> 1) microformats have accessibility problems with <abbr>; time element 
> solves that - but if the only "valid" use is to mark up future events 
> (as Henri suggests), then pages become "invalid" as they age. (Much like 
> me, actually)

Future events are not the only valid use of the element.  It already 
supports dates back to 0001-01-01, which covers a significant proportion 
of historic dates already.  It's just not really optimised for such uses.

> 2) microformats are already used "in the wild" to mark up past events. 
> sometimes ancient and sometimes without DDMMYYYY precision. People who 
> wish to do that won't be able to use <time>, so it perpetuates the 
> accessibility problems it wishes to solve and fragments the way dates 
> are marked up on the Web; some will use time, some will use microformats

Yes, examples of such imprecise dates using microformats have already 
been provided for those, which is a good start, and personally I think 
allowing support for years only (YYYY) or year and month only (YYYY-MM) 
dates is a reasonably easy thing to do.  But the issue still needs 
further investigation to understand what useful functionality consumers 
would gain from such markup.

Specifically:
* Investigation of how it would help users of assistive technology to
   have imprecise dates marked up.  (I mentioned one potential benefit in
   my last email, but, as I said, I'm not certain about it and it needs
   research to confirm it).

* Investigation of how browsers could expose the date to to users in a
   useful way, and an understanding of how and why this would be useful
   for such historic and/or imprecise dates.

* Investigation of other potential consuming applications, such as
   - The SIMILE timeline application that can create timelines from
     marked up events in a page;
   - Date based news searching applications (e.g. searching for news from
     a particular time period).

* Investigation of how imprecise dates affect the ability to import such
   events into a calendar.  e.g. The Sydney Royal Easter show scheduled
   for 2009-04, and takes place over a period of a few weeks in the
   month.  Is it enough to simply say:

<time datetime="2009-04">9?22 April 2009</time>

   Or would it be better to give the precise date range, as

<time datetime="2009-04-09">9</time>?<time datetime="2009-04-22">22 
April, 2009</time>

   Or would supporting a range directly in the datetime field support
   this better:

<time datetime="2009-04-09/2009-04-22">9?22 April 2009</time>

Investigating how hCalendar currently addresses use cases like that 
would be useful in order to address some of the limitations that 
approach may have.

Another case for an imprecise date might be:

<p><time>2009</time> is The International Year of Astronomy.</p>

For this, we would need to understand what real benefit consuming 
applications would gain from that.  It's not really a date that someone 
would want to import directly into their calendar.  But understanding 
what other potential applications, such as those mentioned above, might 
want to do with it would be useful.

> What advantage is there for authors and consumers by *not* extending the 
> range of dates that can be described with <time> ?

That's the wrong question to ask because it places the burdon of proof 
on the wrong side.  But by not addressing every possible little use case 
under the sun, we keep the language simplified and easier for authors to 
learn and use, and we can focus on really optimising for the top ~80-90% 
of the use cases, without spending a disproportionate amount of time 
trying to optimise for the remaining ~10% of edge cases too.

-- 
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/

Received on Thursday, 12 March 2009 06:20:32 UTC