[whatwg] <time> element feedback

Am 31.08.10 21:40, schrieb Aryeh Gregor:
> On Tue, Aug 31, 2010 at 5:25 AM, Martin Janecke<whatwg.org at kaor.in>  wrote:
>> Besides,<time>2010</time>  in a British news article would allow users e.g.
>> in Japan to have these dates displayed as ?22?. That's clearly an advantage
>> over the number 2010 alone.
>
> I would say the opposite.  If they can read the English news article,
> they'll necessarily know what "2010" means.  But they might not be
> able to read Japanese.  Maybe they're borrowing a Japanese person's
> computer, for example, or maybe the browser's idea of the user
> language is otherwise wrong.
>
> Also, content that behaves differently based on the browser settings
> of the viewer is confusing and can cause hard-to-debug problems.
> Users will think that the author of that British article actually
> wrote out a Japanese date, and be completely at a loss to explain why.
>   Even if they can actually understand the date, the incongruity will
> look like a bug.
>
> It could be outright misleading if there are two year display formats
> that look the same but actually have different meaning.  A plain year
> number in Arabic numerals like 2010 could refer to any number of
> totally different year-numbering conventions, and the only way to tell
> them apart currently is the page's context.  Having the browser change
> the number to some convention that doesn't match its surroundings
> makes it impossible to guess the convention.
>
> And finally, it just looks weird.  I would find it extremely strange
> to have all dates on pages I'm reading replaced with Hebrew dates,
> even though I understand those just fine.  I wouldn't want that at
> all, and I find it hard to believe that many actual users do in real
> life.
>
> Basically, any kind of attempt to have browsers localize dates that
> are actually displayed in content is a terrible idea, and the spec
> should remove all mention of any such thing.  I'm pretty sure I've
> said all this before, though.
>

I understand your point, the situation you describe would be unfavorable 
indeed.

However, there's no need to make this unfavorable. The localized display 
of times and dates can be realized via tooltips for example, as it is 
often seen with abbreviations in texts. The localized date doesn't have 
to be a replacement for the original date string but can be a helpful, 
explaining addition.

Furthermore, browsers should not force a localized version upon their 
users. Users should be able to configure their prefered format, just as 
they can set a preferred language or a default charset.

Received on Tuesday, 31 August 2010 13:21:20 UTC