I concur 100%.<br><br>Additionally, I don&#39;t understand why the time element is allowed to specify an arbitrary hour, but not an arbitrary month or year.<br><br>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 &quot;2005&quot;, for instance, is semantically distinct from the numeral &quot;2005&quot;, and though the difference can be inferred from context by a human it can not by a machine, hence why things like &lt;time&gt;2005&lt;/time&gt;, or &lt;time datetime=&quot;2005&quot;&gt;4 years ago&lt;/time&gt; would be useful here. But under the current specification, these uses are invalid, meaning I&#39;d only be able to specify exact dates with meaningful language, as in &lt;time datetime=&quot;2005-01-01&quot;&gt;2005&lt;/time&gt;, and hack around it for inexact dates with non-semantics like &lt;span class=&quot;datetime&quot;&gt;2005&lt;/span&gt;.<br>

<br>This use case (which has nothing to do with calendars) would certainly not be unique to me, as I&#39;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 &lt;<a href="http://people.mnhs.org/dci/faq.cfm#17">http://people.mnhs.org/dci/faq.cfm#17</a>&gt;. 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.<br>

<br>The way I see it, if we can mark up abbreviations without having to expand them fully, or even at all (&lt;abbr&gt;XSLT&lt;/abbr&gt;, &lt;abbr title=&quot;XSL Transformations&gt;XSLT&lt;/abbr&gt;, and &lt;abbr title=&quot;eXtensible Stylesheet Language Transformations&gt;XSLT&lt;/abbr&gt;, or even &lt;abbr title=&quot;cat&quot;&gt;XSLT&lt;/abbr&gt; are all valid) we should be able to mark up datetimes without having to expand them fully.<br>

<br>But don&#39;t take my word for it. I&#39;m sure these articles have been mentioned here before, but Eric Meyer &lt;<a href="http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/">http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/</a>&gt; and PPK &lt;<a href="http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html">http://www.quirksmode.org/blog/archives/2009/04/making_time_saf.html</a>&gt; have also voiced support for a less-restrictive &lt;time&gt; (Hixie has at least seen the former &lt;<a href="http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378">http://meyerweb.com/eric/thoughts/2009/09/02/nine-into-five/#comment-475378</a>&gt;, though there was no further discussion with him about the issue there.)<br>

<br>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.<br><br>Thank you,<br>Hugh<br><br><div class="gmail_quote">
On Sat, Nov 28, 2009 at 7:11 AM, Jeremy Keith <span dir="ltr">&lt;<a href="mailto:jeremy@adactio.com">jeremy@adactio.com</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">We seem to be straying behind the bikeshed a little bit here. My point wasn&#39;t to point out problems with the examples given in &quot;common idioms without dedicated elements&quot;<div class="im">

<br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/commands.html#conversations</a><br>
<br></div>
The real problem is the definition of the &lt;time&gt; element itself:<div class="im"><br>
<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/text-level-semantics.html#the-time-element</a><br>


<br></div>
This sentence:<div class="im"><br>
&quot;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&#39;s calendar.&quot;<br>
<br></div>
...should be changed to:<br>
&quot;This element is intended as a way to encode modern dates and times in a machine-readable way.&quot;<br>
<br>
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&#39;t with those examples; it&#39;s with the definition of &lt;time&gt;.<br>


<br>
HTH,<div><div></div><div class="h5"><br>
<br>
Jeremy<br>
<br>
-- <br>
Jeremy Keith<br>
<br>
a d a c t i o<br>
<br>
<a href="http://adactio.com/" target="_blank">http://adactio.com/</a><br>
<br>
<br>
</div></div></blockquote></div><br>