Discussion on removing 'locale' from DOM3Events

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.

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?