- From: Philip Jägenstedt <philipj@opera.com>
- Date: Tue, 16 Mar 2010 17:47:12 +0800
On Tue, 16 Mar 2010 17:01:00 +0800, Ian Hickson <ian at 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
Received on Tuesday, 16 March 2010 02:47:12 UTC