Bruce Lawson wrote:
On Thu, 12 Mar 2009 17:05:38 +0530, Lachlan Hunt
<lachlan.h...@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/
