[whatwg] Use cases for the time element

[Hugh Guiney]

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 <jeremy at 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/
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20091210/a6ed1d81/attachment-0001.htm>