- From: Bruce Lawson <brucel@opera.com>
- Date: Thu, 12 Mar 2009 17:29:37 +0530
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) 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 Therefore, extending the range of dates that can be marked up with <time> promotes accessibility, and caters for an existing requirement to mark up dates. Why do people want to mark up dates? I don't know. I don't know what people will use datagrid for, but I'm sure they will - and I know there are no clients out there that can use datagrid but that's not a reason to consign it to the bin in a kind of chicken-and-egg reductionism. I know that we don't want to bloat the language with new elements for every conceivable wish, but we're not talking about a new element, we're talking about further extending the usefulness of one. What advantage is there for authors and consumers by *not* extending the range of dates that can be described with <time> ? b
Received on Thursday, 12 March 2009 04:59:37 UTC