W3C home > Mailing lists > Public > public-rdfa-wg@w3.org > November 2011

Re: Looking at the time element (again) (ISSUE-97)

From: Jeni Tennison <jeni@jenitennison.com>
Date: Fri, 11 Nov 2011 16:03:02 +0000
Message-Id: <FFB283BD-DD2D-42B3-B0F3-6596ADAAEC20@jenitennison.com>
To: RDFa WG <public-rdfa-wg@w3.org>
All,

It's worth looking at:

  https://plus.google.com/107429617152575897589/posts/3ZEQAVkF6xd

where Hixie says that <time> will be replaced by "a new <time> element" to cover Tantek's use cases, which I think are the ones at:

  http://www.w3.org/wiki/User:Tantekelik/time_element

In particular, note that these suggestions include accepting formats that the old <time> element didn't, such as years on their own. This extends the amount of sniffing that a processor will have to do on the attribute and/or content of the element.

I don't know how the new <time> element is going to be specced -- it might be that Hixie replaces the datetime attribute with a @value attribute to bring it closer to the <data> element.

Just a thought that if you wanted to reduce the amount of special casing in HTML+RDFa 1.1, you could perhaps:

  (a) define a special datatype called xhv:dateOrTimeOrDuration and have datatype sniffing go on for any value that is typed like that
  (b) state for HTML+RDFa 1.1 that <time> elements are pre-processed to add a datatype="xhv:dateOrTimeOrDuration" and a @content attribute holding the value of the element if there isn't one already, and then processed as normal

Cheers,

Jeni
-- 
Jeni Tennison
http://www.jenitennison.com
Received on Friday, 11 November 2011 16:03:38 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 04:55:18 GMT