W3C home > Mailing lists > Public > public-html@w3.org > November 2011

Re: minutes for HTML WG f2f, 2011-11-04, part 1

From: Cameron Heavon-Jones <cmhjones@gmail.com>
Date: Mon, 7 Nov 2011 16:25:15 +0000
Cc: public-html@w3.org
Message-Id: <E83DFCF4-8B19-499C-87B5-371DDC0226ED@gmail.com>
To: Tantek Çelik <tantek@cs.stanford.edu>

On 06/11/2011, at 12:58 AM, Tantek Çelik wrote:
> Here is the URL to the living change proposal to re-add an enhanced
> time element:
> http://www.w3.org/wiki/User:Tantekelik/time_element
> I'd like to also see the <data> element introduced - there are
> numerous additional uses in microformats for a generic <data> element
> and we can use it over time to gather data on what other (if any)
> specific elements we could use in the future (rather than
> hypothesizing too many up front). There was also rough consensus in
> the HTML WG f2f *for* adding a data element.
> Here is the URL to the living change proposal to add a data element:
> http://www.w3.org/wiki/User:Tantekelik/data_element

The problem with having both <time> and <data> elements is their overwhelming overlap in functionality and implementation. If we need <data>, why do we need a special case for <time>?

The target of these elements is scripting and automated consumption. As a scriptor, if i want all the data marked-up elements on a page am i going to have to inquire for all <data> elements, then merge these myself with all the <time>'s?

If <data> is to be integrated with the html suite and applicable for styling, parsing, formatting etc - where does <time> stand apart from these use cases?

Time is currently handled in a type-discriminated manner for <input>'s, the inclusion of a specific <time> element is a divergence from this well established implementation method.

As a special case, <time> will require special cases for any form of document integration, this will be the same for similarly granular element types: <location>, <unit>, <price>, <blah>, etc which is a non-scalable solution for everyone.

Cameron Jones
Received on Monday, 7 November 2011 16:25:53 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 9 October 2021 18:45:45 UTC