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