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

[Bug 13240] Consider replacing <time> with <data>

From: <bugzilla@jessica.w3.org>
Date: Fri, 12 Aug 2011 21:18:21 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1Qrz7V-0006vj-TF@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240

--- Comment #35 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-08-12 21:18:20 UTC ---
That's one reason why we originally added <time>, but it never seemed to get
much author interest. We got more questions about how to avoid it than how to
use it, if anything.

I don't think the list I gave above is comprehensive. It's just what I could
come up with in about 5 minutes off the top of my head.

There are costs to many elements also. The microdata algorithms, for instance,
would have to special-case them all. Validators would have to know all the
various ways they can be used. There's the documentation, testing, and tutorial
cost.

I don't think the analogy to <input> works here, because this element would be
non-interactive and wouldn't have multiple modes: it would just be one feature
that could be used for many things. It's like how class="" can be used for many
different things, but it's still just one feature.

Exactly what format you would use for various data types would depend on the
vocabulary. For example if you had a data field that had to express a date
range with error bars it could be:

   <data value="2010-03-12±4 ..  2011-01-05±3">

...or it could be:

   <data value="2010-03-08:2010-03-16 2011-01-02:2011-01-08">

It's really up to the author. And note that this data format wouldn't be
possible with any of the elements I listed, so we'd have to add yet another one
to the list...

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
Received on Friday, 12 August 2011 21:18:23 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 16:31:16 UTC