[whatwg] proposal: extend <time> to markup durations

[Tantek Çelik]

On Thu, Jul 14, 2011 at 14:51, Tab Atkins Jr. <jackalmage at gmail.com> wrote:
> On Thu, Jul 14, 2011 at 2:36 PM, Ian Hickson <ian at hixie.ch> wrote:
>> On Thu, 14 Jul 2011, Tantek Ã~Gelik wrote:
>>> Some in the microformats community have been making good use of the
>>> <time> element, e.g. for publishing hCalendar, and implementing
>>> consuming/converting hCalendar [1] with good success.
>>> [1] http://microformats.org/wiki/h2vx#HTML5_support
>>>
>>> It would be great if the <time> element could support expressing
>>> durations as well for the use cases as needed by the hMedia and hAudio
>>> microformats as well as other use-cases (Wikipedia, IMDB).
>>>
>>> Simple proposal, examples, faq, discussion (please contribute)
>>>
>>> http://wiki.whatwg.org/wiki/Time_element#duration
>>
>> I haven't studied the above yet, but I just wanted to bring up a trial
>> balloon for a possible alternative solution: drop <time> and replace it
>> with a generic solution.
>>
>> There are several use cases for <time>:
>>
>> A. Easier styling of dates and times from CSS.
>>
>> B. A way to mark up the publication date/time for an article (e.g. for
>> conversion to Atom).
>>
>> C. A way to mark up machine-readable times and dates for use in
>> Microformats or microdata.
>>
>> Use cases A and B do not seem to have much traction.


Use case A hasn't been a priority for anyone in the CSSWG no.

However, use case B is being incrementally adopted, both as specified
for pubdate, e.g.:
* https://singpolyma.net/blog/
* http://adactio.com/journal/

and using <time> with the hAtom microformat in particular rather than
pubdate (thus avoiding DRY violations with the help of the
microformats value class pattern)
* http://tantek.com/

There's probably more out there - but there are a few real world
example you can try out.


>> Use case C applies to more than just dates, and the lack of solution for
>> stuff outside dates and times is being problematic to many communities.

True. However the primary real-world use case of C has been hCalendar events.
Publishing example at http://tantek.com/
And consuming/parsing implementation: http://dev.h2vx.com/ics/

I'd say use cases "more than just dates" require open documentation on
a public wiki, otherwise we're designing from "theoretical needs"
which are pretty low priority IIRC.


>> Proposal: we dump use cases A and B, and pivot <time> on use case C,
>> changing it to <data> and making it like the <abbr> for machine-readable
>> data, primarily for use by Microformats and HTML's microdata feature.
>
> I'm fine with this,

I'm not and I think it's a mistake because <data> (and the <abbr>
pattern before that when liberally applied) leads to encouraging lazy
double-encoding of data which is a DRY violation (and thus bad for
{meta}data accuracy/quality over time).

Instead I think the <time> element approach is correct.

First prove the need for double-encoding on a case by case basis, and
then create an element for each proven data-type use-case.

E.g. next on this list IMHO would be a  <number> element for example,
since it's clear from some of the examples where quantities or numbers
are involved - e.g. the hReview-aggregate microformat, that publishers
use human/locale/design-specific numbers

e.g.
<number value="10000">10,000</number>
<number value="10000">10.000</number>
<number value="10000">10k</number>

etc.

Obvious FAQ:

"Won't we end up with a billion new tags?" (actual expression from
IRC, not deliberate strawman)

No we won't.

No matter how you slice it there will be a very limited number of
specific data types that require dual representation (evidence: all
existing schema languages have a small fixed number of atomic scalar
types).

I would be surprised if more than half dozen or so data-type-specific
elements were added ever for this, I could be mistaken, but I'd rather
be proven wrong by evidence demonstrating 5-6 are not enough, than
overgeneralizing now.


> but as I expressed when this was discussed
> earlier, I think this should be more explicitly aimed at Microdata,
> with something like <itemdata @itemprop @data>...</itemdata>.
> This makes it less immediately applicable to Microformats...

A @data *global* attribute would work equally well for Microdata,
microformats, and RDFa, and yes would be preferred over a <data>
element, so no need to worry there.


> but in my
> opinion Microformats should switch to using Microdata as their
> embedding syntax, as that would solve their "you have to write a
> custom parser for each vocab" problem.

Simpler and more incremental (based on existing practice) solution to
the customize-parser-per-microformat-problem already under way here:

http://microformats.org/wiki/microformats-2

Certainly not as fully specified as microdata yet, but I expect all
the same RDF/JSON generation algorithms will work - and the syntax
will be simpler for typical developers and typical web pages.


> (I want to address usecase A at some point, but it's a complicated
> problem that I don't have anywhere near the bandwidth for.  It doesn't
> necessarily require <time>, though - <itemdata> would work just fine
> if CSS specified a particular date format that the data had to be in.)

Agreed on all counts. I proposed a language/locale specific
"date-style" property (akin to "list-style-type") in a CSS WG meeting
years ago (2003 or 2004 I think) but it didn't generate sufficient
interest at the time (nor since).

Thanks,

Tantek
-- 
http://tantek.com/ - I made an HTML5 tutorial! http://tantek.com/html5