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.


 Jens.


[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

http://meiert.com