<time> element change proposal

Summary

Enhance the <time> element in HTML5 as follows:

current functionality with the following simplifications:
- drop DOM attribute 'valueAsDate'
- default rendering element contents (rather than attribute presented per local prefs)
plus support for year-only dates per [1] (e.g. vCard4 RFC6350 / hCard 'bday' use-case)
plus support for year-month only dates per [2] ("")
plus support for month-day only dates per [3] ("")
timezone per [4]
duration per [5]

The above feature set was presented to the HTML Working Group on 2011-11-03, and among those that support a time element in general, there was acceptance of and no objections to the list of above additions to the time element.

Given the level of consensus shown during face-to-face discussions on this particular feature set, I consider the feature set frozen for the purposes of this change proposal, with the exception of including additional changes that help build consensus around this change proposal. So far that includes:

support for year week only dates per [6]
support for a space (U+0020) as an alternative to 'T' as the date/time separator in date-and-time microsyntaxes per [7]

This change proposal explicitly does not include other proposals from http://wiki.whatwg.org/wiki/Time_element, however anyone wishing to advocate for additional features is encouraged to write their own separate delta change proposal that adds to this current proposal.

This is a change proposal to address:

http://www.w3.org/html/wg/tracker/issues/183

Rationale

Use-cases: The time element is quite useful, for publishers wanting to express which numbers and prose represent aspects of time, to consuming applications converting or indexing time related content, to end users who wish to read (or listen to) times and dates in their (perhaps locale) preferred format.

Advantage over alternative: A time element is also more semantically specific than a generic data element (which is still useful in its own right for other types of data that require different human vs machine representations). While many of the above use-cases can be partially addressed using a generic data element by implying the types of time from the fairly unique microsyntaxes of machine-readable dates and times (ISO8601), this approach has a number of flaws:

existing non-unique microsyntaxes. Some microsyntaxes, such as for the year (YYYY) just look like a number. Others like year-month (YYYY-MM) or year-month-day (YYYY-MM-DD) could easily be confused with microsyntaxes for things such as part numbers which are often sequences of numbers separated by one or more dashes. The time (HH:MM) could be confused with references to citations to verses, e.g. "20:30", or lengths of music tracks, e.g. "2:28".
future-friendliness. date time related microsyntaxes could be useful for other data types in the future. Depending on microsyntax uniqueness for inferring type of data restricts our future potential use of those microsyntaxes.

Details

See summary for now. Can be expanded as necessary / requested by editor.

Impact

Positive Effects

Helps accessibility. Above and beyond a plain <data> element, when publishers mark something up with the <time> element, it provides the opportunity for accessibility tools to present (speak) the date or time value in the user's personally preferred and/or locale-specific date-time format thus making the content more accessible, even internationally so. The alternative, simply using a generic <data> element, lacks this capability, because the attribute value is opaque and cannot be assumed to be any kind of human readable/speakable/listenable content.
Helps real-world search use-case. Google's search user interface provides the option to search by date range (whether this is for mentions of dates or publication date or date modified is unclear). With the <time> element, such search use cases could provide much more accurate results. Currently Google has to make guesses and has many false positives. E.g. an actual attempt to search for the earliest documentation of ActiveX from site:microsoft.com when narrowed by decade returned results from 1972 (Microsoft was established in 1975) and 1977 (long before the web existed, much less Internet Explorer).

Negative Effects

One more element. Each additional element adds complexity and incremental cognitive load to learning and using the language.

Conformance Classes

As defined in previous draft with the time element, expanded to allow the additional features as noted above.

Risks

There are risks that publishers will errantly markup date and time information incorrectly.
Potential DRY violation/rot. In cases where the author publishes the machine-readable datetime information in addition to the human-readable element content, there is a chance of drift between the two and the machine data rotting since the human-readable element content is seen by more people and more likely to get fixed when necessary.

References

References are inline.

User:Tantekelik/time element