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

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

From: <bugzilla@jessica.w3.org>
Date: Wed, 02 Nov 2011 13:33:16 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RLawO-00088C-Sn@jessica.w3.org>
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13240

BenB <7xnm24bdza@snkmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |7xnm24bdza@snkmail.com

--- Comment #55 from BenB <7xnm24bdza@snkmail.com> 2011-11-02 13:33:13 UTC ---
(In reply to comment #36)
> Is there any data showing how people actually use <time> in practice? i.e. is
> it actually giving anyone any of its hypothetical benefits?

tl;dr: It's useful to show shortened or "friendly" versions of full timestamps.
I would suggest either reverting this change, or adding a type attribute to
fully replicate the time element.

(Note: I am speaking personally in this comment and not in any official
capacity on behalf of my employer)

I can't offer broad data but I can say we've implemented the <time> element in
production versions of several Atlassian products (Confluence, JIRA, Bamboo,
BitBucket). It never occurred to me at least that such a useful element would
get removed from the spec.

The most common use case is retaining full timestamps in the DOM while still
providing shortened, localised or "friendly" times ("5 minutes ago"), eg:

<time datetime="2011-11-02T16:23:30+11:00">7 hours ago</time>

We've used this pattern on wiki editing diff pages, BitBucket change history
pages, build activity screens, etc.

The data element as proposed seems to lack the disambiguation of the time
element... to achieve the same result we would have to add more markup, eg. in
the form of microdata, or simply hope all data elements in the document happen
to be a time. Since we have products working with user-generated content and an
ecosystem of plugin developers, relying on such a broad convention would be
poorly advised.

So by this change we effectively lose the ability to simply, unambiguously mark
up a time or date with a single element. We either add attributes to wrapper
elements, or we rely on a weak convention of not using data for anything other
than time - which suggests it should just stay <time> in the first place.

I wouldn't object to the data element being *added* to the spec in addition to
time, although I can't really see much use for it without some form of type
attribute to allow different uses to coexist, eg:

<data type="datetime" value="2011-11-02T16:23:30+11:00">7 hours ago</data>

However to my mind time is such a common use case it seems appropriate to
retain the specific element.

-- 
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 Wednesday, 2 November 2011 13:33:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 2 November 2011 13:33:33 GMT