Re: Discussion on removing 'locale' from DOM3Events

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