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: Thu, 03 Nov 2011 01:15:28 +0000
To: public-html-bugzilla@w3.org
Message-Id: <E1RLltw-0001jt-DV@jessica.w3.org>

--- Comment #66 from Ben Buchanan <7xnm24bdza@snkmail.com> 2011-11-03 01:15:25 UTC ---
(In reply to comment #56)
> Ben, can you elaborate on what you actually *do* with the <time> element? Is it
> as a convenient styling hook, do you have scripts that operate on it, is it a
> convention for plugin developers to scrape dates from the markup (as opposed to
> giving them access to the backend representation), or something else? (I
> presume it is not just "retaining full timestamps in the DOM", since having a
> value in an attribute by itself doesn't do anything.)

Styling is not particularly the driver for using <time>; although it does give
an efficient and convenient selector for style and scripting.

Note that I didn't personally implement time in all our products so I can't
provide the full deep dive of details... however one specific use case reported
is BitBucket uses jQuery.localize to convert UTC timestamps to localized

We anticipate plugin devs will make use of <time> but it's a bit too early to
expect a swathe of usage - these things do take a while to settle in. <time>
has not really been a stated or promoted convention, since semantic markup is
basically self-explanatory to people who want to manipulate the DOM.

To expand the thought a bit, we do have a pure-DOM plugin system alongside our
more deeply-integrated/backend plugin system. The DOM system is commonly used
for greasemonkey-style customisation by users (hence why people would use the
DOM and not access backend data directly).

We are in the process of converting our UI to HTML5 (doctype switch first) and
<time> was a common early choice based on ease of implementation and solving a
common problem (working with human- and machine-readable time information). I
feel I should point out this use case should not be downplayed just because it
sounds simple.  We used <time> because that's what it's for and we show a lot
of times in our UI; and we want to have access to both the full timestamp and a
human-readable version of that information.

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 Thursday, 3 November 2011 01:17:33 UTC

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