[whatwg] Please consider <time> syntax processing improvements for better DRY and thus more accurate data over time

[Tantek Çelik]

We know from experience with past methods of duplicated invisible
(meta)data, and more recently, development/use/experience with visible
microformats, that when we are able to re-use the visible data,
published *once*, by humans for humans, we get more accurate data over
time, than when we have at times asked for *duplicating* the data in a
different (more machine readable) format (or location).  This
experience yielded the microformats adoption of the DRY principle -
don't repeat yourself - in application to (meta)dataformat designs and
techniques.


The <time> element currently encourages DRY violations in most of its
use cases (duplication of datetime information inside the 'datetime'
attribute in addition to the visible content of the element). This is
not a new problem, we've had much the same DRY problem in microformats
representations of dates and times, originally with (excessive and in
many cases inaccessible) use of the <abbr> element.

Subsequently (through years of debate, experimentation, iteration)
we've largely addressed both most of the DRY violations (or greatly
mitigated their impact) and resolved accessibility related <abbr>
problems with the introduction and successful adoption of the Value
Class Pattern (developed in parallel with the time element, and not
surprisingly with some newer improvements).

http://microformats.org/wiki/value-class-pattern#Date_and_time_values


We'd like to see the lessons learned (and improvements made as a
result of the value class pattern) adopted in HTML5 as well, for much
the same reasons, to make the HTML5 <time> element the best and most
long term accurate way to represent all date and time information in
microformats (or microdata for that matter).

Accordingly, please consider the following <time> syntax processing
improvements for better DRY (and mitigation) and thus more accurate
data over time.


1. composite nested time elements.

In short, instead of this (actual example derived from markup of blog
post HTML5 watch[1] by Jeremy Keith)

<time class="published" datetime="2009-12-13T17:43:29">
  Sunday, December 13th, 2009
  5:43pm
</time>

We want to be able to do this:

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
  <time datetime="17:43:29">5:43pm</time>
</time>

and have the parent <time> element composite a complete datetime from
the child <time> elements with separate date and time.

The datetime values are more readable (per accessibility research
etc.), and thus more easily human verifiable as being the "same" value
as the in-content text, thus resulting in incrementally more accurate
data over time.

This type of date and time compositing as spec'd in the Value Class
Pattern has been interoperably implemented and shipped (Operator,
X2V).  Thus we think it is reasonable to add this similar feature to
HTML5.


More details, examples, use-cases here:

http://wiki.whatwg.org/wiki/Time_element#composite_nested_time_elements

I encourage web developers and browser implementers to add their
opinions and comments to that wiki page section.



2. am pm and coarser time parsing

Summary: by permitting am pm and coarser time values, many more
instances of time markup can be minimized to in-content only (not
requiring a datetime attribute) and thus reduce many DRY violations.

In short, instead of this (actual example derived from markup of blog
post HTML5 watch by Jeremy Keith, with nested time elements per
previous proposal)

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
  <time datetime="17:43:29">5:43pm</time>
</time>

We want to be able to do this:

<time class="published">
  <time datetime="2009-12-13">Sunday, December 13th, 2009</time>
  <time>5:43pm</time>
</time>

It's a minor DRY improvement (time info is no longer duplicated), but
one that we think is worth it across the numerous pieces of content
authored as such and the resulting increased accuracy from DRY
reduction.

This type of am pm parsing as spec'd in the Value Class Pattern has
been interoperably implemented and shipped (Operator, X2V).  Thus we
think it is reasonable to add this similar feature to HTML5.


More details, examples, use-cases here:

http://wiki.whatwg.org/wiki/Time_element#am_pm_and_coarser_time_parsing

I encourage web developers and browser implementers to add their
opinions and comments to that wiki page section.


Thanks for your consideration,


Tantek


[1] http://adactio.com/journal/1632/

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