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

Re: XHTML 2.0 <datetime> element proposal

From: Lachlan Hunt <lhunt07@postoffice.csu.edu.au>
Date: Thu, 30 Oct 2003 23:06:24 +1100
Message-ID: <3FA0FEC0.9020701@postoffice.csu.edu.au>
To: www-html@w3.org


 > Only some thoughts: It seems to me that it's at first necessary to 
see why
 > and where I need such a <datetime /> element (or anything similar), 
and I came
 > to the conclusion that you don't inevitably need it for simple rendering
 > purposes. -- So I assume that the most common case is the desire for 
different
 > displaying, not for more comfortable evaluation opportunities.
 >

Rendering of the date is left for style sheets, this would not be a 
presentational element.
(See below)

 > So if there are different versions of a document (indicating different
 > languages), there is no problem to use an alternative date/time 
scheme on any of
 > these documents. If there is only one document displaying various 
language
 > sets, I question the need for this element, too, because it would 
neither be a
 > problem to also use different time formats there, nor would it reduce the
 > probability for only confusing users (ain't it confusing -- and even 
not reliable
 > -- visiting a French site but encountering an American date format)? This
 > IMO only brings up Usability and Accessibility problems.

If you visited a French site (or any other language for that matter), 
you would most likely encounter a date in that country's format.
This is a problem if you are not french.  Ofcourse, a translator may 
have been used to view the site in the first place, but if a *numeric* 
date was encountered, how would a translator recognise it as a date, 
and, thus, know how to translate it?

 >
 > Last but not least, I think there is already a sufficient and generic 
way to
 > indicate date and time, see Dublin Core [1], although having the same
 > characteristics as mentioned above (defining normally only one 
specific format for
 > an release/update date or period). An user agent might parse this in 
a user
 > demanded way, too, like expected from the (preferred?) 'attribute 
version'.
 >

Dublin core is for meta data, not xml markup, plus it seems to be based 
on ISO 8601.

 > Better keep the markup simple.
 >
 >
 > Jens.
 >
 >
 > [1] http://dublincore.org/documents/date-element/
 >


  A datetime element would be useful because it would designate a piece 
of data as a date and/or time.  Without it, if you encounter a date on a 
webpage that contains a date like 02/04/03, what does that mean?  2 
April 2003? 4 February 2003? 03 April 2003?  It's impossible to tell, 
without looking at the origin of the web page and then figure out "how 
do they write dates in that country?". [1]

  Using the <datetime> tag would eliminate this need.  The content could 
be in any format that the author wished to write, however the attribute 
would specify, unambiguously, what the date and time represents.

eg.  The following example content are all written in different formats, 
however their semantic meaning given by the <datetime> tag remains the 
same.  This eliminates the ambiguity of some of these for the user 
agent, therefore, providing a way for a user to get a translation upon 
request.

<datetime datetime="2003-10-30T20:00+10:00">2003-10-30, 20:00</datetime>
<datetime datetime="2003-10-30T20:00+10:00">30/10/2003, 8:00pm</datetime>
<datetime datetime="2003-10-30T20:00+10:00">
    <span class="day">Thursday</span>,
    <span class="date">30<sup>th</sup></span> <span 
class="month">October</span> <span class="year">2003</span>,
    <span class="time">20:00</span>
</datetime>

NOTE: this allows developer to format this
      content in any way with CSS, without
      affecting the meaning of the datetime,
      which is specified by the datetime
      attribute

  Authors writing XHTML documents would learn the ISO 8601 format, and 
therefore not have a problem using it in the attribute, but for the 
general public reading the documents, date formats can cause problems.  
ie.  A lot of people may not understand the ISO format; thus, writing 
something like the following may be difficult to read and understand for 
some people -- likewise if any other date/time format was used.:

  <p>A meeting will be held on 2003-10-30T20:00+10:00 to discuss...</p>

  It would be better to be able to write:

  <p>A meeting will be held on <datetime 
datetime="2003-10-30T20:00+10:00">30<sup>th</sup> October 2003, at 
8:00pm<date> to discuss...</p>

NOTE: I think, Providing a <datetime> tag might
      start to make authors consider how they are
      writing dates in their documents, and maybe
      start avoiding the use of ambiguous formats
      (eg. 02/04/03). Wouldn't that be Great!!!

  The use of the 'datetime' attribute would match its use as currently 
defined in section 6.4 Edit Collection of the XHTML2.0  (W3C Working 
Draft 6 May 2003).  Thus, I propose moving this attribute to a datetime 
collection or module, along with a new <datetime> tag, then the 
attribute may be incorporated into other elements if required.  This 
also gives a reason to make the name of the tag <datetime> since the 
term is already used for the attribute, and because it's not 
representing just a time, or just a date -- It can be both.

  There are, however, other questions that would need to be addressed 
should the <datetime> element be accepted, such as:
1. Could <datetime> tags be nested? (eg. for marking up a calendar, or 
diary, where dates can be in the same year/month and times can be on the 
same day)
2. Does the datetime attribute require the full YYYY-MM-DDThh:mm:ss 
format, or should it support other variants (YYYY-MM-DD, YYYY-Www-DD and 
hh:mm:ss) [1]

[1] http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html

CYA
...Lachy
Received on Thursday, 30 October 2003 07:06:26 GMT

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