[whatwg] Use cases for the time element

[Hugh Guiney]

On Thu, Dec 10, 2009 at 9:06 AM, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> 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?

Yes, ideally I would like to store all of my data as XHTML+XML. Though
I suppose I could describe that data with an arbitrary vocabulary
server-side, sort on that, and transform the result into HTML, it
makes the script much smaller and easier to write if there's a common
syntax in place.

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

It just seems to me that *requiring* this sort of specificity (rather
than simply allowing it) is contrary to the typically rather
permissive nature of HTML. If we don't even need to close our tags,
why do we need to specify whole dates? As far as I know, there hasn't
ever been an element that made validation fail because of a malformed
microsyntax; why start now? ISO 8601 (which has been footnoted by the
W3C since 1997) allows for several levels of granularity, up to the
year. What is it that necessitates this particular level of
granularity (aside from adding dates to calendars, which is only one
use case)?

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

I agree.

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

I realize that, but the fact that he was able to write that much on
the topic just strengthens the argument that <time> has far more use
cases than it's been allotted, and as such, its current definition
needs to be addressed, be it in that capacity or smaller.