RE: Discussion on removing 'locale' from DOM3Events

Super. Gary will be updating the spec with this change.

From: Wez [mailto:wez@google.com]
Sent: Thursday, October 24, 2013 5:44 PM
To: Takayoshi Kochi (河内 隆仁)
Cc: Travis Leithead; garykac@google.com; masayuki@d-toybox.com; www-dom@w3.org; Jianfeng Lin
Subject: Re: Discussion on removing 'locale' from DOM3Events

This sounds like a reasonable approach to me.

On 18 October 2013 01:53, Takayoshi Kochi (河内 隆仁) <kochi@google.com<mailto:kochi@google.com>> wrote:
Hi Travis,

I couldn't join the last telcon, due to a conflicting schedule.
Replies inlined.

On Thu, Oct 17, 2013 at 2:44 AM, Travis Leithead <travis.leithead@microsoft.com<mailto:travis.leithead@microsoft.com>> wrote:
Kochi,

On the DOM 3 Events call yesterday, we were reviewing all the issues in the spec. At this point, we’re driving toward a publication in time for TPAC, which only gives us about 1.5 weeks! Many of the issues are just naming questions about certain key names, but one of the bigger open issues is about the under-specified “locale” property.

As a refresher, locale is specified in two places in the current DOM L3 Spec: KeyboardEvent.locale, and CompositionEvent.locale.

Here’s the requirement for KeyboardEvent.locale:


The locale DOMString attribute contains a BCP-47 tag [BCP-47<https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#ref-BCP-47>] indicating the locale for which the keyboard originating the event is configured, e.g. "en-US". The locale MAY be the empty string<https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#glossary-empty-string> when inapplicable or unknown, e.g. when this information is not exposed by the underlying platform.
Note

Note: locale does not necessarily indicate the locale of the data or the context in which it is being entered. For example, a French user often might not switch to an English keyboard setting when typing English, in which case the locale will still indicate French. Nor can it be used to definitively calculate the physical or virtual key associated with the event, or the character printed on that key.

The text for CompositionEvent.locale:

The locale DOMString attribute contains a BCP-47 tag [BCP-47<https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#ref-BCP-47>] indicating the locale for which the IME originating the event is configured, e.g. "ja", "zh-Hans", "ko". MAY be the empty string<https://dvcs.w3.org/hg/dom3events/raw-file/tip/html/DOM3-Events.html#glossary-empty-string> when inapplicable or unknown, e.g. when this information is not exposed by the underlying platform or application.
Note

Note: locale does not necessarily indicate the locale of the data or the context in which it is being entered. For example, a French user often might not switch to an English keyboard setting when typing English, in which case the locale will still indicate French, even though the data is actually English. Similarly, an IME application could fail to distinguish between the locale of Chinese and Kanji characters.
The current UI Events spec (https://dvcs.w3.org/hg/d4e/raw-file/tip/source_respec.htm#widl-KeyboardEvent-queryLocale-DOMString) defines a static ‘KeyboardEvent.queryLocale()’ which will report the locale of the configured keyboard. This seems to wholly subsume the use-case for including KeyboardEvent.locale as a property of the event object. Furthermore, it can be queried at any time, even when a keyboard event is not being dispatched. I can imagine some other useful additions we could make to UI Events in the future, such as events that fire when the keyboard locale changes. Also, perhaps KeyboardEvent is not the right interface to put this data. Anyway, all of these questions can be further debated as we turn our attention to the UI Events spec upon completion of DOM L3 Events.


Sounds okay to me.  As far as I heard, the reasoning of attaching locale attribute to every key event,
which may sound a weird place -  is a privacy concern; if such information can be obtained without
any user's typing (like queryLocale()), it can leak private information of its OS/hardware configuration
just by accessing such a page or ads.
IMO it's very conservative and I personally don't care much as it's almost the same feeling as leaking screen size
and so on, which is already available today, and that typing a key is equivalent to consent that "this browser
lets the page know your keyboard locale!" would be hard to understand for everyone, but let's be sure to be warned ;)

Probably such concerns, if any, should be addressed by putting it in per-page/site permissions
like "allow geolocation on ths page".

Given the above, I don’t see any problem with dropping KeyboardEvent.locale from DOM L3 Events.

The question is what to do about CompositionEvent.locale. Right now, the active work happening in the W3C related to IME’s and composition, is happening in the IME API spec (https://dvcs.w3.org/hg/ime-api/raw-file/default/Overview.html). There are already a few interfaces in the IME spec that are good candidates for merging onto the CompositionEvent interface (see note related to the “interface Composition”). I think for the purposes of providing a more complete description of “locale” and locating the definition of the property closer to the scenarios in which it will be used (and also in the interest of reducing the active issues in DOM L3 Events spec), I propose that the IME API spec adopt the ‘locale’ property, and that we remove it from DOM L3 Events.

For the IME API, this would be as simple as adding a new section that extends DOM L3 Event’s CompositionEvent in the form of:
partial interface CompositionEvent {
   readonly attribute DOMString locale;
};

The particulars of what this string returns will then need to be more carefully thought out, since BCP-47 is very wide-open in terms of scope, and we want to be able to have interoperable implementations of this property.

How does this proposal sound to you?

It sounds reasonable to me, and even adding "keyboard locale changed" event you mentioned above
could belong to the IME API.
I will work on updating / incorporating it in the IME API spec.

Thanks,
--
Takayoshi Kochi