W3C home > Mailing lists > Public > www-html@w3.org > October 2003

XHTML 2.0 <datetime> element proposal

From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
Date: Thu, 30 Oct 2003 04:20:44 +1100
Message-ID: <3F9FF6EC.7020701@postoffice.csu.edu.au>
To: www-html@w3.org

Hi,
  I would like to propose that XHTML implement a <datetime> element for 
the purpose of rendering, obviously, dates and times.  I have noticed 
some messages in the archives from a few months ago that mention various 
date tags and formats, but none that I thought provided a really good 
option.

I have come up with several alternatives for this.


Version 1:
  The first places each field in a separate tag, as follows:

<datetime calendar="gregorian" locale="au" tz="+10:00">
    <day>Tuesday</day>
    <date>28</date>
    <month>10</month>
    <year era="CE">2003</yr>
    <time>13:10:15</time>
</datetime>

This has the advantage that older browsers that won't support the tags 
will still render the content such as:
 "Tuesday 28 10 2003 13:10:15"
which is atleast readable, though not perfectly formatted.  However new 
browsers that do understand the tags will be able to apply, (also older 
browsers that support CSS, if it provided by the author) will be able to 
format the date in a presentable manner such as:
"Tuesday, 2003-10-28 13:10:15"

  Plus, browsers from other languages will see the calendar, locale and 
tz (timezone) attributes and be able to perform calculations, or other 
formatting to present the date in the user's preferred format, or even 
convert to a different calendar.  xml:lang may also be used here to 
specify the language, if it is different from the rest of the document.
  The era (which would default to CE) attribute also allows historians 
to write dates as BCE.

  Note: I am proposing the use of CE (common era) and BCE (before common 
era), instead of AD and BC because of the relationship of the latter to 
christianity.

  It may also be an option to use <hour>, <min> and <sec> tags, rather 
than just the single <time> tag, but it may be unnecessary to break time 
down that far.


Version 2:
  Alternatively, this could be written with each field as attributes, 
and have default text, for rendering in older user agents, within the tags.
Using CSS, this default content could be hidden, as in the <object> tag, 
for example, and use the attributes when printing the date, or perform 
conversions before rendering by the browser.

<datetime calendar="gregorian" locale="au" era="CE" year="2003" 
month="10" day="Thursday" date="30" hour="13" min="10" sec="15" 
tz="+10">Thursday, 10 October 2003, 13:10:15</datetime>

  Possible CSS to render this could be written like this (or some other 
variant):
datetime:after {
    content: attr(day) + ", " + attr(date) + "-" + attr(month) + "-" + 
attr(year) + ", " + attr(hour) + ":" + attr(min) + ":" + attr(sec);
}


Version 3:
  The third version simply specifies the calendar, locale, era and tz, 
along with a format, as follows:
<datetime calendar="gregorian" locale="au" tz="+10:00" era="CE 
format="dddd, dd-MM-yyyy, HH:mm:ss">Tuesday, 30-10-2003, 13:10:15</datetime>
  This would allow user agents to understand the format that the date 
has been written in, and allow alternative rendering, or conversions to 
be performed.


Version 4:
  My final version simply uses an attribute that specifies the 
international format, with default text rendered within, as before.

<datetime datetime="2003-10-28T13:10:15+10:00">Tuesday, 10 October 2003, 
13:10:15</datetime>

  However, I see two problems with versions 3 and 4:
a) The browser would need to support this tag to be able to reformat the 
date in any way.  I'm not aware of any css that can process a string 
like this ("2003-10-28T13:10:15:00+10:00") to seperate content, reformat 
and display.

b) It would mean that authors would have to take care that they wrote 
the date, following the format exactly.  If an error was made, such as 
using '-' instead of ':', or omitting the T, or anything else, user 
agents may find it useless, and unable to process.

  Thus, I prefer either my first or second alternative because it 
clearly seperates each field, making it easier for authors, and CSS 
designers to format.  Perhaps some combinations of these four 
alternatives that I have not considered could be used.
Received on Wednesday, 29 October 2003 12:20:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 March 2012 18:15:58 GMT