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

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.

Thanks,
Cameron Jones

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