User:Tantekelik/time input match

From W3C Wiki


<time> <input> elements match change proposal

Summary

Enhance the <time> element in HTML5 to provide additional output capabilities to match the new date-time <input> element capabilities as follows:

  • support for year-only dates, year-month only dates, and month-day only dates per the User:Tantekelik/time_element change proposal
  • support for year week only dates per [1]

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.

There is currently no separate tracker issue for this proposal. Such a issue could be created, based in issue 4 mentioned here: http://lists.w3.org/Archives/Public/public-html/2011Nov/0186.html

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.

The new date time <input> elements are also quite useful.

These two do not currently match up.

The enhancements listed in the summary above allow the time element to fully represent all the different types of date time information that the new date time inputs can capture.

Details

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

Impact

Positive Effects

  • Provide a more consistent date time input/output model for web authors.

Negative Effects

  • Makes the spec slightly longer.

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.

Related