From W3C Wiki
< User:Cjones
Revision as of 15:26, 9 February 2012 by Cjones (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Change Proposal for ISSUE-183: Drop the <time> element


This is a counter-proposal to the enhancement of the <time> element advocated for resolution of ISSUE-183. This proposal recommends the removal of the <time> element from HTML5 by replacement with the prerequisite addition of the <data> element in ISSUE-184.

The functionality currently available within <time> and the supplementary functionality advocated in the original proposal is recommended to be integrated into HTML5 through the addition of date and time parsing rules for values represented in the <data> element.

This proposal references an additional proposal for enhancement of the <data> element by extending Tantekelik's proposal for ISSUE-184 through the addition of a "type" attribute for discriminating parsing rules allowing for the additional functionality to be maintained.


The addition of a <data> element provides the necessary method for authors to markup machine readable data within HTML documents. The addition of the <data> element renders the <time> element obsolete by means of duplication of declarative functionality.

This duplication would cause confusion for authors over the scope of such element and which method to use and in what context.

For documents rendered by server processing and substitution the additional <time> element would either require special case programming constructs for handling times and dates, or would result in the <time> element not being used by automated document generation machines in favor of the simpler and more generic <data> element.

This duplication would also complicate any scripted processing of HTML documents on the client or by search engines or other applications. Such scripts and applications would be forced to deal with two data sets of date and time information resulting in more complicated programming requirements and introducing unnecessary risk of errors and information omission.

This damage is also not limited to scripted applications but also CSS style rules which must also deal with duplication of targeting and rules. Since the means for styling dates, times and other data through CSS is still under active development this introduces unacceptable risk and complications to this development and specification process.

In summary, unless <time> is dropped the fundamental programming principal of Don't Repeat Yourself (DRY) will be violated causing all of the negative effects and risks associated with violation of this rule.


  1. Remove the <time> element and all associated attributes
  2. Replace the time and date parsing instruction set with the <data> element
  3. Update the time and date parsing instruction set with the additional rules introduced by Tantekelik's proposal to ISSUE-183


Positive Effects

  • The DRY principal that "Every piece of knowledge must have a single, unambiguous, authoritative representation within a system" is maintained
  • The method for marking up data information is simple, generic and universally applicable to all data types
  • The expressiveness of the
  • The additional enhancements provided by Tantekelik proposal are realized
  • The development of CSS style rules for data is not imposed with undue complexity

Negative Effects

  • Experimental uses of <time> are rendered obsolete and require updating. Since these authors are ahead of the curve they are aware of the potential that changes may occur. The upgrade path is simple requiring only substitution of element name and may encourage these authors to extend their support of <data> to more use cases improving the corpus of machine readable data on the web.

Conformance Classes Changes

  • <time> is non-conformant element
  • Conformance Class Changes required to support Tantekelik's propsal


  • Without the supplementary addition of a <data> 'type' attribute discriminator, the additional processing rules introduced with Tantekelik's proposal may introduce complex data parsing rules. See the supplementary counter-proposal to ISSUE-184 for more information.


  • ISSUE-183: Enhance and simplify the time element [1]
  • Tantekelik's propsal for ISSUE-183 [2]
  • ISSUE-184: Add a data element [3]
  • Tantekelik's propsal for ISSUE-184 [4]
  • CJones' supplementary counter-proposal for ISSUE-184 [5]