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

Summary

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 through the addition of the <data> element as its replacement with a "type" attribute for discrimination over values as proposed in the supplementary proposal for the resolution of ISSUE-184 [5].

Rationale

The rationale for this proposal examines the definition of the <time> element in its ability to represent date and time information and compares this with the alternate solution of a generic <data> element.

Element Granularity

The <time> and <data> elements represent the semantic markup of machine readable information on alternate levels of graduation.

The <data> element is a generic element which is semantically capable of representing any type of primitive or elementary data within documents and provides this capability in a universal manner which is irrespective of the type of data. This primitive data is able to be compounded into complex data types through the application of data markup technologies.

The <time> element is semantically targeted at a lower level of granularity with the explicit restriction of its capacity to representing only date and time information. This satisfies the immediate requirement for this ability, however by targeting semantic tags at this level the future considerations of new and additional data types is both unaddressed yet the semantic precedence is set to promote the addition of new elements as the solution.

There are a number of new data types which are not representable at present for which there has been requirement to cater for, including: "location", "color", "currency", "telephone", "number" etc. The implementation of these using the approach applied to date and time information with new elements would represent a significant addition to the specification with the only benefit being to authors who find semantic element names more memorable than semantic attribute names. This is due to all of these elements sharing the same identical use case and purpose which is for marking up elementary machine-readable data.

The means for marking up data using a <data> element represents a scalable solution to this problem by allowing for new data types to be added without the need for them to be defined and implemented through the specification of new elements and satisfies the use case succinctly with a single element fit for purpose.

Discrimination of Denominations

The <time> element consists of an attribute definition "datetime" which holds the machine-readable data value and the contents of the element, if present, is defined to be the label. The specification of <time> allows for numerous denominations (year, month, date, etc) to be represented within this element however the means for defining the denomination of this value is defined through the syntax of the "datetime" attribute.

This has the impact that the denomination of the date\time value can not be simply identified and must be resolved through the resolution of HTML microsyntax.

This affects document generation systems which are unable to work direct with standard machine readable encodings and must mutate these encodings by applying the microsyntax rules instead of using the simpler and less error prone approach of an enumerated type discriminator for denoting the denomination over date\time encodings.

This also affects document consumers or scripts which are unable to lookup dates and times within a document by enumerated discriminator and instead must resolve these manually through the application of the HTML microsyntax algorithm.

The approach used by <time> is divergent from that used within the <input> element and its use of type discrimination through enumerated attribute values. This represents a conceptual overloading of syntactical implementation which complicates the HTML model and does not leverage the opportunity for a reduction in conceptual complexity.

The lack of type discrimination within <time> also represents a limitation in the flexibility of the potential denominations as type resolution is deferred to the encoding syntax. This places a direct correlation between the flexibility of the encoding to the distinction of type limiting the potential for satisfying future requirements and resulting in certain date and time values being unrepresentable within the element. For example, this can be seen through the lack of ability of the <time> element and its microsyntax from being able to represent abstract dates and times due to them being unrepresentable and inextensible in the microsyntax.

This problem is not encountered in the implementation of <data> with a type discriminator attribute which, in addition to supporting all the date and time denominations currently afforded to <time> and <input>, also leaves scope for the extension of new denominations using newly defined discriminations and allows for denominations to be marked up and looked up through simple enumerated values.

Duplication of Declarative Functionality (DRY Principle)

The addition of the <data> element provides the necessary method to markup machine readable data within HTML documents. This renders the <time> element obsolete by means of duplication of declarative functionality as all types and values which can be encoded within <time> can also be encoded within <data>.

The proposal for retaining <time> does not specify for <data> to be omitted, so as <data> is capable of representing all date\time types and values, the inclusion of both methods will invariably result in both being used by authors due to confusion arising from duplication and\or due the simplicity of programatically generating all data types using a single element construct.

This is expected to be encountered in documents produced for proprietary machine consumption where priority is given to the simplicity of internal application communication over 3rd party consumption and standards compliance.

Data Rendering with Localization and Formatting

The use case for the addition of <time>, and by extension <data>, is that of data representation within documents. This requirement not only represents the ability for data values to be encoded and consumed but also for them to be interfaced by the browser.

The interfacing over data, like form fields, is relatively under specified at present due to the deferment to implementation which provides the necessary exploration and definition for specification and design. The requirements for this are evident through the extrapolation from the needs of authors and users to represent and restrict variation required for serving the user base encompassing all countries, languages and preference.

The means for delivering this functionality is dependent on a number of factors which are represented with markup - the data value, the locale\language and author customization or configuration.

The complexity in delivering this functionality is due to the intersection between the otherwise distinct separation between model and style within HTML and CSS.

This proposal does not provide a solution herein, however the use of <data> instead of <time> represents a simplification of the problem through the limitation of scope to a single element instead of being dispersed across multiple element definitions. In addition, the synchronicity between the implementation of discrimination type attributes in <data> and <input> elements provides the means to define a universal solution across synonymous data-driven elements which share an identical type system with localization and formatting declarations for external stylesheet customization.

Details

Remove the <time> element and all associated attributes
Apply the changes required by extending the <data> element with a type attribute from the supplementary proposal to ISSUE-184 [5]
Define the valid states for the <data> element "type" attribute for date and time types as: year, month, week, date, time, datetime, datetime-local
Define the machine readable value of a <data> element with a date\time type as the value derived through the application of the corresponding HTML microsyntax in section 2.5.5 Dates and times.

Impact

Positive Effects

The method for marking up data information is simple, generic and universal
The expressiveness of the element is retained
The ability to extend the markup of date\time information is available
HTML is not bloated with numerous elements all for the same use case and purpose
Automated document generation machines can generate data markup using a single method in standard ISO date\time encodings instead of manipulating encodings for denomination identification through the HTML microsyntax
Scripts and document consumers can lookup value denominations by enumerated discriminator instead of introspecting using the application of HTML microsyntax
The negative impacts of violating DRY principals are eliminated
The development of localization and CSS style and formatting rules for data is not imposed with divergent elements and 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 the addition of the <data> element and a "type" discriminator attribute [5]

Risks

None identified

References

ISSUE-183: Enhance and simplify the time element [1]

Tantek's propsal for ISSUE-183 [2]

ISSUE-184: Add a data element [3]

Tantek's propsal for ISSUE-184 [4]

CJones' supplementary counter-proposal for ISSUE-184 [5]