On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson <i...@hixie.ch> wrote:
This e-mail is a reply to a number of e-mails on various topics relating
to the more document-related elements of HTML.
On Mon, 16 Nov 2009, Philip Jägenstedt wrote:
http://www.whatwg.org/specs/web-apps/current-work/multipage/rendering.html#the-time-element-0
"When the time binding applies to a time element, the element is
expected to render as if it contained text conveying the date (if
known), time (if known), and time-zone offset (if known) represented by
the element, in the fashion most convenient for the user."
This is very vague. Anything which tries to localize the date/time will
fail because guessing the language of web pages is hard. Hard-coding it
to English also wouldn't be very nice. What seems to make the most sense
is using the "best representation of the global date and time string"
and equivalents for just time and date that have to be defined. Still,
I'm not sure this is very useful, as the same rendering (but slightly
more flexible) could be accomplished by simply putting the date/time in
the content instead of in the attribute. As a bonus, that would degrade
gracefully. Unless I'm missing something, I suggest dropping the special
rendering requirements for <time> completely.
The idea is to render the date or time in the user's locale, not the
page's, though I agree that in some cases that could be confusing.
Maybe we should leave the localising behaviour to author CSS and not do
it
automatically by default?
I think that would be better, yes. Either that or a spec saying exactly
what string to output for each possible locale. (Making it platform- and
browser-dependent is just asking for trouble.)
--
Philip Jägenstedt
Core Developer
Opera Software
