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

Re: XHTML 2.0 <datetime> element proposal

From: Christoph Päper <christoph.paeper@tu-clausthal.de>
Date: Thu, 30 Oct 2003 03:54:31 +0100
Message-ID: <04ae01c39e91$25138a70$3ef4ae8b@heim4.tuclausthal.de>
To: <www-html@w3.org>

*Tantek Çelik*:
> On 10/29/03 2:03 PM, "David Woolley" <david@djwhome.demon.co.uk> wrote:
>> In any case, if there is a case for a special element, in my view it
>> must include the ISO format date.

And only that.

>> I would suggest there is a significant case for making it the
>> content rather than an attribute,

For reasons of backwards compatibility and non-styled readability for Joe
Sixpack I'd prefer to put the ISO value into an attribute.

>> and treating localisation of the date as a styling issue.


> I agree.  Something very simple like
>  <time>2003-10-29T15:00-08:00</time>
> would be very useful. ("date" is just a special designation for a subset of
> time values). And then challenge the CSS folks to come up with a mechanism
> to declaratively restyle arbitrary ISO8601 date time strings into various
> locale dependent legacy forms.

Some .us page (xml:lang="en-US"):
  <time value="2003-10-29T15:00-08:00">Today, 3 PM PST</time>

My user stylesheet:
  @localtime Z+01 {
  time[value]:lang(en) {content: time(attr(value), DD) " "
                                 time(attr(value), MMM) " "
                                 time(attr(value), YYYY) ", "
                                 time(attr(value), hh) ":"
                                 time(attr(value), mm);

Result in browser on my computer:
  29 October 2003, 22:00

That doesn't work too well when there're further elements nested inside
<time/>, though. It is quite long, too.

> Similarly, I have encountered instances where a frequency element would
> have been quite useful.  Something like:
>  <freq>88.5mHz</freq>

IMO a generic method to combine value and unit is much preferable, like
<data><val>88.5</val> <unit>mHz</unit></data>.

A year ago I proposed a single element to do it all in one:
I'm rather convinced today that that's not the best way to do it, but still
believe there should be one.

> In any case, rather than waiting to add such new elements to XHTML 2.0, why
> not simply create your own XHTML Modularization module[1] for them and

Yes, why not, but you should be sure about the best or at least a good way to
do it before even starting to write such a module.
Received on Wednesday, 29 October 2003 21:56:10 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:06:05 UTC