Re: CSS Localization

On Wed, Jan 28, 2015 at 7:14 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
> On Wed, Jan 28, 2015 at 6:00 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>> On Tue, Jan 20, 2015 at 11:49 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>> On Sat, Jan 17, 2015 at 6:04 AM, Cameron Jones <cmhjones@gmail.com> wrote:
>>>> On Fri, Jan 16, 2015 at 7:28 PM, Tab Atkins Jr. <jackalmage@gmail.com> wrote:
>>>>> Reiterating my earlier point, if the *users* are giving some explicit
>>>>> instruction, it's much more effective for them to give it to the
>>>>> browser itself, so the browser can apply their wishes to *all* pages,
>>>>> not just those who went to the trouble of setting everything up
>>>>> correctly.  If the user's wishes can be accommodated in an automatic
>>>>> way, the browser can do it better than the page; if the wishes can't
>>>>> be accommodated automatically, then providing browser-level
>>>>> functionality for it doesn't seem helpful.
>>>>>
>>>>
>>>> So every multilingual site which is currently using the 'national
>>>> flag' UI pattern should instead try to inform uses how to change their
>>>> locale in each of the browser preference panels?
>>>
>>> They shouldn't try to do anything at all.  The browser-provided inputs
>>> are formatted according to the computer's locale already, which is
>>> *probably* correct; and if it's not, it's not the responsibility of
>>> individual websites to correct for that.  (If it's incorrect, the user
>>> is at least probably *used* to the incorrect display, and has learned
>>> how to work with it.)
>>>
>>
>> The national flag pattern is precisely for when the browser's locale
>> is incorrect with respect to what the user wants and they are
>> incapable either by technical restriction, inadequacy or persistent
>> inconvenience to change the configuration.
>
> No.  You keep conflating multiple things here - browser-provided
> inputs and the rest of the page's content - and it's making it very
> difficult to maintain a consistent narrative, as there are different
> responses to each of them.

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.

Given that the new form inputs are still experimental, i think that
what the expected behavior should be is still to be fully determined.

>
> As far as I can tell, there's no reason for a page to have control
> over the locale of a browser-provided input.  Most of the time, user's
> computers are in the right locale already, and when they're not, the
> user is at least probably *used to* the locale they're stuck in, so
> they can anticipate things like date ordering in OS/browser-provided
> things.  Giving individual pages the ability to control these would
> just mean that pages would be inconsistent with the user's locale
> sometimes.  Even if there was a use-case, this sort of control is an
> "attractive nuisance" that authors are likely to reach for commonly
> because it *seems* right to them, so we'd have to be careful in how we
> expose it to minimize the chance of it being over- (and incorrectly-)
> used.

OK, i fully understand your point of view.

>
> On the other hand, the content on the rest of the page is already
> fully under the page's control, and there's plenty of localization
> tools in various server-side programming languages to handle that.
> Most content can't be automatically localized (such as text), which is
> why the "flag pattern" exists, because instead you just have to create
> parallel pages (I've done this myself several times).  If you're doing
> parallel pages for different locales, you can and should adapt the
> dates/times/etc in-page yourself - a German-language page should be
> using DD/MM/YY order for dates, while an American-language page should
> be using MM/DD/YY.  There is no need for the browser to provide
> additional help for this, as it's already fully possible and easy for
> authors to do it themselves.
>

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.

>>> For all the content provided by the page, rather than the browser,
>>> they already have the localization tools necessary to deliver things
>>> in the format they want - the national flag UI pattern.  If you can
>>> localize the text yourself, you can localize everything that's not
>>> browser-provided yourself.
>>>
>>
>> But sites won't be able to localize the form inputs to use the same
>> locale the user chose through the national flag UI pattern.
>>
>> If they do use the new form inputs they will have a mix of locales in
>> effect on the same page.
>>
>> This is the worst case scenario for localizing a page and represents a
>> step backwards for existing sites. These sites won't transition to
>> using the new form inputs if they can not replicate their current
>> functionality in the new controls.
>
> No, this is a *preferred* scenario.  If I'm a German speaker and I go
> to a site's German version, my computer is *probably* already set up
> with a German locale, and the inputs will already reflect that
> (assuming the input reflects my locale at all).  If I'm an American
> who has to, for some reason, visit a German-language page (for
> example, to buy train tickets), I want the inputs to be formatted in
> the American style, like the rest of my computer.
>
> If I'm a German who has a computer that is stuck in an American
> locale, I've probably already gotten used to this, and will expect all
> inputs to use the American format - confusing, but at least it's
> consistent, so I can muscle-memory my way through.  And vice versa.
>
> The worst-case scenario is if I can't predict what date format a
> page's inputs will be using, and so I read a date wrong and get bad
> information.  This is what would happen, though, if pages could
> control the locale of their inputs.
>

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.


>>> 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.


>> The argument about people being hurt by providing access to this
>> functionality is advocating for a sterile environment where browsers
>> must protect against nefarious or incompetent site developers. It's
>> always possible for programmers to write abusive routines - anyone can
>> include the following JS on any page today:
>>
>> while(true) {
>>   // burn!!
>> }
>>
>> With power comes responsibility - but the net impact of misusing or
>> abusing a page's locale would be the incomprehension of that
>> individual page, so the damage is limited to their own purposes.
>
> We guard users against authors misusing features all the time.
> Hyperbolic arguments aside, this is standard practice in standards
> design.
>
>>>>> No, there's significant difference.  Inputs contain well-known data
>>>>> types, and don't require any parsing or similar, just formatting.
>>>>> Arbitrary data requires parsing and datatype tagging.
>>>>
>>>> You still need parsing when dealing with inputs - the user can do free
>>>> text entry which needs to be parsed against the format.
>>>
>>> That's against a single spec-defined grammar, though.  Dates, for
>>> example, have to be in the form YYYY-MM-DD if you set the input
>>> directly.  That's only barely "parsing". ^_^
>>
>> Hmm...i was more thinking that the format skeleton would provide the
>> ability to enter values within that format.
>>
>> Wouldn't it be more confusing for users if the format changes when
>> they focus the input field?
>
> I'm unsure what you're talking about. I was referring to today's
> world.  Today, if you give an <input type=date> a value directly, it
> must be of the form YYYY-MM-DD.  (This is only relevant if you're
> setting the value from script; Chrome, for example, does allow direct
> date entry in the UI, but exposed it in the more familiar MM/DD/YYYY,
> which is allowed on the UI side.)

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"?

>
>> 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 and shouldn't be
configurable, and i was trying to show that there are numerous
variations on how dates can be formatted which shows that it has
presentational properties.

Since dates in ISO-8061 are precise and unambiguous there seems little
value in having formats defined within HTML as their meaning will
never change with differing styles of presentation.

In addition, defining a format skeleton in HTML would need to be done
for each date element and would not be able to make use of CSS
selector targeting or the other benefits which come with the
separation of presentation attributes in CSS.

Thanks,
Cameron

Received on Thursday, 29 January 2015 15:58:17 UTC