I concur 100%. Additionally, I don't understand why the time element is allowed to specify an arbitrary hour, but not an arbitrary month or year.
My own use case involves marking up years of publication for documents I have created, to be displayed in an online resume that can be sorted by date. I do not necessarily have the original timestamps for every file, yet I can recall the years in which they were published. In this case, the year "2005", for instance, is semantically distinct from the numeral "2005", and though the difference can be inferred from context by a human it can not by a machine, hence why things like <time>2005</time>, or <time datetime="2005">4 years ago</time> would be useful here. But under the current specification, these uses are invalid, meaning I'd only be able to specify exact dates with meaningful language, as in <time datetime="2005-01-01">2005</time>, and hack around it for inexact dates with non-semantics like <span class="datetime">2005</span>. This use case (which has nothing to do with calendars) would certainly not be unique to me, as I'm sure there are many events well-within the Gregorian calendar that have inexact dates, such as the dates of deceased family members for whom incomplete records were kept during the time of their death <http://people.mnhs.org/dci/faq.cfm#17>. Rather than just presented textually, the results could be marked up in HTML and extracted using an API, browser add-on, or other software that reads the metadata and returns something useful to the user, such as an automatically-generated genealogical entry file that can be imported into a family tree program—much in the way the Operator Toolbar extension for Firefox currently reads hCards and automatically generates contact entry files that can be imported into e-mail programs. The way I see it, if we can mark up abbreviations without having to expand them fully, or even at all (<abbr>XSLT</abbr>, <abbr title="XSL Transformations>XSLT</abbr>, and <abbr title="eXtensible Stylesheet Language Transformations>XSLT</abbr>, or even <abbr title="cat">XSLT</abbr> are all valid) we should be able to mark up datetimes without having to expand them fully. But don't take my word for it. I'm sure these articles have been mentioned here before, but Eric Meyer < http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/> and PPK < http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html> have also voiced support for a less-restrictive <time> (Hixie has at least seen the former < http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378>, though there was no further discussion with him about the issue there.) If these issues have already been discussed, please point me in the right direction so that I can better understand the decision to phrase the spec this way. Thank you, Hugh On Sat, Nov 28, 2009 at 7:11 AM, Jeremy Keith <jer...@adactio.com> wrote: > We seem to be straying behind the bikeshed a little bit here. My point > wasn't to point out problems with the examples given in "common idioms > without dedicated elements" > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations > > The real problem is the definition of the <time> element itself: > > > http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element > > This sentence: > > "This element is intended as a way to encode modern dates and times in a > machine-readable way so that user agents can offer to add them to the user's > calendar." > > ...should be changed to: > "This element is intended as a way to encode modern dates and times in a > machine-readable way." > > The overly-restrictive clause at the end canonises a single use case as the > only usage of the element. The fact that there examples elsewhere in the > spec that contradict this definition highlights the problem, but the issue > isn't with those examples; it's with the definition of <time>. > > HTH, > > > Jeremy > > -- > Jeremy Keith > > a d a c t i o > > http://adactio.com/ > > >
