Re: Discussion on removing 'locale' from DOM3Events

On 10/16/2013 08:44 PM, Travis Leithead 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.
The reason why .locale was added to key events was that one shouldn't be able to fingerprint user if user isn't even interacting with certain page.
That issue hasn't gone anywhere, so why are we changing .locale?


> 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.
>
> Given the above, I don’t see any problem with dropping KeyboardEvent.locale from DOM L3 Events.

But I do see problem adding queryLocale()


This all was discussed when .locale was added.

-Olli


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

Received on Friday, 25 October 2013 20:02:47 UTC