Re: CSS Localization

On Thu, Jan 29, 2015 at 7:20 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Thu, Jan 29, 2015 at 7:57 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>> I don't think i'm conflating multiple things but instead it appears
>> that we share different viewpoints on what users may regard as
>> expected behavior.
>
> They're different things because one is controlled by the browser and
> the other is controlled by the page author.  Those are very different.
>
>> Given that the new form inputs are still experimental, i think that
>> what the expected behavior should be is still to be fully determined.
>
> They're not experimental in any meaningful way.  They've been in
> browsers for years.
>

Current browser compatibility charts would seem to disagree:

http://www.quirksmode.org/html5/inputs.html

The pending "Intent to Implement" from Chrome would also disagree with this:

https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/QpEoCwU0Ttg


>> The benefit of client-side localization with specific regard to date
>> formatting is that HTML can be written with only the data values and
>> formatting can be applied on a site-wide basis through CSS stylesheets
>> and as a part of the CSS hierarchy of property resolution including
>> browser and user stylesheets.
>>
>> It depends on whether this is regarded to have enough utility to
>> warrant its inclusion.
>
> In your example (flag-UI localization), the entire rest of the page is
> manually localized already, so a new CSS feature to localize a small
> amount of the data doesn't seem warranted.

Opinion on Chrome's "Intent to Implement" would seem to disagree.

>
>> I think the notion of what *you* can't predict and what a "normal"
>> user can't predict are different.
>>
>> I would say that a "normal" user would be more confused by having
>> different date formats on the same page, rather than having an
>> intricate knowledge of which parts of the page change and which don't
>> depending on what language they choose.
>>
>> It would seem that for an uninitiated user there is the potential for
>> confusion on first encounter regardless of which approach is in place.
>
> It's "the things I can type in, which always look about the same on
> every page on the entire internet" and "the rest of the page".  I'm
> pretty sure users can tell the difference between those two things.
>

I don't think that users make such a distinction by default. Users
tend to react more favorably to consistency. The argument would seem
to stem to as whether consistency within the browser across all pages
vs consistency within a single page.

To return to a previous point you raised about users being capable of
understanding form inputs in different languages - what about the use
of different calendar systems? How is a user supposed to decipher a
Vietnamese calendar written in Vietnamese script? What about alternate
number systems? Only regarding the minor differences between US and UK
date formats or even all latin-based languages is trivial in
comparison to the differences which can be exhibited within all
localizations.

See here for some of the complexity in other calendar systems which i
doubt any non-native user would be able to decipher:

http://cldr.unicode.org/development/development-process/design-proposals/chinese-calendar-support

>>>>> You still haven't explained why someone would want to do any of this.
>>>>> Very specifically:  what user, in what situation, would be helped by a
>>>>> page setting this?  And, importantly, would they be hurt by pages
>>>>> doing this for languages other than their own?
>>>>
>>>> A Chinese person working in LAX airport using shared access terminals
>>>> running a webapp which provides a locale setting may want to configure
>>>> their login to use their chosen localization without having to change
>>>> browser settings on every login and inadvertently affecting other
>>>> users of that terminal.
>>>
>>> That's a very specific scenario, and I don't think it can generalize
>>> very far either.  It can also be addressed by having multiple accounts
>>> at the OS level, or multiple accounts at the browser level (Chrome,
>>> for example, offers this now), either of which would address the
>>> situation well.
>>>
>>
>> That kind of goes against the concept of what a webapp should be
>> capable of, imho.
>
> I don't understand why?

Because applications run within a host environment which provides APIs
for creating any type of application without assuming a particular
mode of operating and proscribing and restricting what is possible.

A document rendering environment like MS Word would impose a degree of
restriction based on a more limited scope of operation which defines
it as an application itself and not an application environment.

>
>> I meant that shouldn't it be possible to control the format of date entry?
>>
>> So for example, i could configure Chrome to display and allow text
>> entry in the short form "MM/DD/YY"?
>
> This is the crux of my entire argument, which I've made repeatedly -
> no, I don't think it's a good idea to allow a page to do that kind of
> thing.  Yes, I think the OS should be able to do that kind of thing.
>

That seems quite draconian and overly restrictive to me. So if an
application developer wants to have that sort of control they
shouldn't be writing HTML and CSS but should develop OS applications
instead?

The problem within proscribing a single date format is that there are
cases when developers may want to use longer, more expressive date
formats which could definitely not be proscribed for all uses. Why
should someone be restricted from formatting a date input like "Friday
30th January 2015" when the vast majority of users won't be mutating
the text directly but using a calendar popup widget to select a
particular date? Having the date in a more readable form may be
desirable for their particular instance of use.

>>>> It should probably always be possible for ISO-8061 text entry, but for
>>>> this to be the only format seems very technical and not so user
>>>> friendly.
>>>
>>> Again, this is the format required for setting the input.value directly.
>>>
>>>>>> Surely you must agree that formatting is stylistic and will be specified in CSS?
>>>>>
>>>>> I don't agree.  Formatting is meaningful (for example, some calendars
>>>>> can't display some dates), and I haven't seen any reason for the
>>>>> browser-supplied things to make this configurable so far.
>>>>
>>>> There are almost limitless ways of formatting dates, especially if we
>>>> consider dates formatted with author supplied text strings.
>>>>
>>>> You seem to be advocating for a single date format for all purposes -
>>>> there are many situations where anything from very short to very long
>>>> formats are in widespread use and not just for visual layout.
>>>>
>>>> Whether a date contains the day of week, a numerical month or a verbal
>>>> month, a 4 digit year or a 2 digit year - these are all common
>>>> variations and not possible for a "one-size-fits-all".
>>>
>>> That is not even remotely what I said.
>>>
>>> ~TJ
>>
>> I was trying to ask whether you think formatting has any place in CSS,
>> your response was that formatting is meaningful
>
> In that it's not fully stylistic; some dates can't be represented by
> all calendars, for example.
>
> ~TJ

I'm not sure what relevance that has? There always has to be
translation between different calendars and the gregorian ISO-8061
date format. If an ISO-8061 date can't be represented within specific
calendar the closest representation will have to be used and any
change to that selection will have to be translated back into
ISO-8061. There doesn't seem to be any way around this regardless of
whether the calendar is specified in HTML or CSS. As long as the
translation is predictable and repeatable that would seem to be the
best that can be accomplished.

Thanks,
Cameron

Received on Friday, 30 January 2015 15:43:19 UTC