[whatwg] Use cases for the time element

[Tab Atkins Jr.]

On Thu, Dec 10, 2009 at 4:09 AM, Hugh Guiney <hugh.guiney at gmail.com> wrote:
> 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>.

Are you planning on using the information in <time> to *do* the
sorting?  That is, when someone chooses "sort by date", do you have
scripting that searches in each section for a <time> and extracts the
date to determine where in the order it should go?


> 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.

Fairness isn't a justification for putting anything in the spec,
fortunately.  Each piece of the spec has to justify itself.


> 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.)

I agree with Meyer on the first one.  That's a useful case.  In
addition, <time>'s usefulness in Microdata is somewhat impaired by its
inability to mark up months or years.  These are by far the most
common 'fuzzy dates' that one would have to mark up for embedded
metadata.  Their lack means that vocabularies need to structure
themselves to take two dates per real 'date', to allow such fuzziness,
which means that date *ranges* would need *four* dates specified.
That's just silly.

However, the second one isn't quite an argument for expanding time.
It's an outlining of, *if* we decide that we want <time> to be useful
for *all* dates, how we should go about doing it.  ppk recognizes that
such an approach may not be what the spec wants.

~TJ