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

Re: XHTML 2.0 <datetime> element proposal

From: Jens Meiert <jens.meiert@erde3.com>
Date: Thu, 30 Oct 2003 09:18:19 +0100 (MET)
To: www-html@w3.org
Message-ID: <24204.1067501899@www42.gmx.net>

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.

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.

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'.

Better keep the markup simple.


[1] http://dublincore.org/documents/date-element/

> *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.
> Okay.
> > 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:
> <http://lists.w3.org/Archives/Public/www-html/2002Nov/0110.html>
> 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.

Jens Meiert
Interface Architect

Received on Thursday, 30 October 2003 03:18:39 UTC

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