Re: proposal: add input/keyboard locale to text and keyboard events [ISSUE-119]

1. What about handwriting and voice? Both should be highly
language-dependent, so conceptually there should be no problem with
assigning to these events an input locale. Are they covered by keyboard
and/or composition events?

2. An application may not need the power of working with keyboard and/or
composition events, but much prefer the simplicity of text events. For such
an application, the feature would be killed (although I admit that this is
stronger language than warranted).

Aharon

On Thu, Dec 2, 2010 at 7:15 PM, Jacob Rossi <jrossi@microsoft.com> wrote:

>  I don't see how this kills the feature. If input locale can only be
> determined for  keyboard and IME scenarios due to platform conventions, then
> KeyboardEvent and CompositionEvent cover all scenarios where locale is
> available. No sense in putting it on TextEvent if it doesn't cover any
> additional scenarios.
>
> If evidence can be given that having the property on TextEvent would cover
> scenarios that aren't captured by KeyboardEvent or CompositionEvent, then
> I'd be for it. But as of now, I only see 2/10 inputMethods being able to
> have two interoperable implementations--both of which are covered by
> Keyboard and Composition Events.
>
> Sent from my Windows Phone
> ------------------------------
> From: Aharon (Vladimir) Lanin
> Sent: Thursday, December 02, 2010 12:59 AM
> To: Jacob Rossi
> Cc: www-dom@w3.org; schepers@w3.org; jonas@sicking.cc; annevk@opera.com;
> hbono@google.com; Travis Leithead
> Subject: Re: proposal: add input/keyboard locale to text and keyboard
> events [ISSUE-119]
>
>
>  > Placing [in inputLocale] property the on KeyboardEvent
> > interface seems appropriate. However, I don’t believe
> > putting it on TextEvent will work out well. The issue is
> > that we can determine locale information when the
> > inputMethod is keyboard or IME, however it is difficult or
> > impossible to do so for the other input methods.
>
>  The proposal is that the property will be null or undefined when the
> information is not available - such as for input methods where it does not
> make sense, or platforms where the information is inaccessible. What's wrong
> with that? Given that the most general-purpose API is text events, why kill
> the feature there because it can't be provided in some cases?
>
>  > For example, platforms don’t expose locale information
> > for paste/drop data in most cases. Furthermore,
> > pasted/dropped content could even contain data with
> > multiple locales in it.
>
>  All true. Which is why I proposed that inputLocale should be null or
> undefined for paste/drop events.
>
>  > I don’t think it’s likely we’ll be able to get two useful and
> > interoperable implementations with locale defined for
> > more than just IME and keyboard input methods.
>
>  There is no reason it should not work for handwriting, which is
> language-dependent and starting to become available on touchscreen devices.
> I would guess that it should work for voice too. Platform interoperability
> is likely to be a challenge, initially, but eventually things should get
> standardized sufficiently to enable browser makers to provide this
> information.
>
>  > In light of this, I propose that instead of TextEvent we
> > place this on CompositionEvent (in addition to
> > KeyboardEvent).
>
>  CompositionEvent seems like a good place for it too, but I don't see why
> it has to be instead of TextEvent.
>
>  Aharon
>
> On Wed, Dec 1, 2010 at 9:57 PM, Jacob Rossi <jrossi@microsoft.com> wrote:
>
>>  We have looked at this further and we’re willing to hold off on specing the global object for this and rather just put it on event interfaces. Placing such a property the on KeyboardEvent interface seems appropriate. However, I don’t believe putting it on TextEvent will work out well. The issue is that we can determine locale information when the inputMethod is keyboard or IME, however it is difficult or impossible to do so for the other input methods.
>>
>>
>>
>> For example, platforms don’t expose locale information for paste/drop data in most cases. Furthermore, pasted/dropped content could even contain data with multiple locales in it. Additionally, locale isn’t well defined for multimodal or script sources. I don’t think it’s likely we’ll be able to get two useful and interoperable implementations with locale defined for more than just IME and keyboard input methods.
>>
>>
>>
>> In light of this, I propose that instead of TextEvent we place this on CompositionEvent (in addition to KeyboardEvent).
>>
>>
>>
>> So to reiterate what this looks like:
>>
>>
>>
>> On the KeyboardEvent and CompositionEvent interfaces, add a readonly attribute DOMString called inputLocale which is the BCP-47 formatted locale code of the inputted character data.
>>
>>
>>
>> Useful resources:
>>
>> [1]  List of BCP-47 language/region subtags:   http://www.iana.org/assignments/language-subtag-registry
>>
>> [2]  BCP-47: http://www.rfc-editor.org/rfc/rfc4646.txt
>>
>> [3]  MSDN - LCIDs to BCP-47 codes: http://msdn.microsoft.com/en-us/library/ff531705(office.12).aspx
>>
>>
>>
>> -Jacob
>>
>>
>>
>> On Wed, Oct 6, 2010 at 2:16 AM, Jacob Rossi <jrossi@microsoft.com <jrossi@microsoft.com?Subject=Re%3A%20proposal%3A%20add%20input%2Fkeyboard%20locale%20to%20text%20and%20keyboard%20events%20%5BISSUE-119%5D&In-Reply-To=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E&References=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E>> wrote:
>>
>>
>>
>> >  > 2010/9/14 Aharon (Vladimir) Lanin <aharon@google.com <aharon@google.com?Subject=Re%3A%20proposal%3A%20add%20input%2Fkeyboard%20locale%20to%20text%20and%20keyboard%20events%20%5BISSUE-119%5D&In-Reply-To=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E&References=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E> <aharon@google.com <aharon@google.com?Subject=Re%3A%20proposal%3A%20add%20input%2Fkeyboard%20locale%20to%20text%20and%20keyboard%20events%20%5BISSUE-119%5D&In-Reply-To=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E&References=%253CAANLkTimrjys4iogu7cZ-SwysbSs8A4HASdrTonDqPs0S%40mail.gmail.com%253E>?Subject=Re%3A%20proposal%3A%20add%20input%2Fkeyboard%20locale%20to%20text%20and%20keyboard%20events%20%5BISSUE-119%5D&In-Reply-To=%253CAANLkTinRgy4NrS59v6jS70XtiV1m%3DzowRa63KPHMNTwP%40mail.gmail.com%253E&References=%253CAANLkTinRgy4NrS59v6jS70XtiV1m%3DzowRa63KPHMNTwP%40mail.gmail.com%253E>>:
>>
>> >
>>
>> > >> Perhaps it should then be redefined as .lastInputLocale, indicating the
>>
>> >
>>
>> > >> locale of the last text input device to have generated input. But then if
>>
>> >
>>
>> > >> the last text event was due to a paste operation, would it become null? If
>>
>> >
>>
>> > >> yes, then the input locale is no longer available outside the scope of
>>
>> >
>>
>> > >> events until the next time there is input. And if no, then during the
>>
>> >
>>
>> > >> paste's text event its value would be misleading (it has nothing to do with
>>
>> >
>>
>> > >> the pasted text). I guess it could become null during the paste text event,
>>
>> >
>>
>> > >> and then go back to the last non-null value after the event is over, but
>>
>> >
>>
>> > >> this is getting a little complicated.
>>
>> >
>>
>> > >> What's wrong with putting the value right in the event, where the is no
>>
>> >
>>
>> > >> possible ambiguity?
>>
>> >
>>
>> > >> Mind you, I agree that having the input locale available outside the scope
>>
>> >
>>
>> > >> of events would indeed be useful too. Perhaps (some global
>>
>> >
>>
>> > >> object).lastInputLocale should be made available in addition to inputLocale
>>
>> >
>>
>> > >> in the events. It would get updated on every text and keyboard event with a
>>
>> >
>>
>> > >> non-null inputlocale.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > Actually, there's a good argument for not exposing inputLocale outside
>>
>> >
>>
>> > > of text/keyboard events. If it is required that the user interact with
>>
>> >
>>
>> > > the page before exposing locale, then this reduces the ability to
>>
>> >
>>
>> > > fingerprint the user.
>>
>> >
>>
>> > >
>>
>> >
>>
>> > > / Jonas
>>
>> >
>>
>> >
>>
>> >
>>
>> > An additional use case would be spell-checker or auto-complete language
>>
>> > detection heuristics. We’ve done a lot of work to better support
>>
>> > international keyboards and IMEs. This API would give better context to such
>>
>> > input and likely has a variety of use cases we haven’t even identified.
>>
>> >
>>
>> >
>>
>> >
>>
>> > I prefer the implementation of an always available API (though, I think
>>
>> > document.inputLocale makes more sense). It seems to me that the user is
>>
>> > likely to change his/her language settings at a much slower rate than that
>>
>> > of the firing of textInput or the keyboard events. For many uses that I can
>>
>> > think of, if the locale is only surfaced through these events, then you will
>>
>> > end up having to cache the value and check for changes at each input event.
>>
>> > This seems like a lot of extra work when you could just be notified of
>>
>> > changes (which probably aren’t that frequent).
>>
>> >
>>
>> >
>>
>> >
>>
>> > Further, some usage of locale is more likely to be reactionary to **
>>
>> > changes** in the current setting rather than at the time of input.
>>
>> > Consider my example of auto-complete. If a user switches his/her input
>>
>> > language, the site would have to wait for input from the user in order to
>>
>> > react to the change. If rather the page was notified at the moment of
>>
>> > language change, then the page might have extra time before the user’s input
>>
>> > to fetch data that might be useful for that specific language (e.g.,
>>
>> >  language-specific auto-completions).
>>
>> >
>>
>> >
>>
>> >
>>
>> > I also think we should not consider pasting clipboard data as an unknown
>>
>> > locale. Outside of the web browser, pasted data would be considered with
>>
>> > whatever the user’s current input locale settings are. I don’t believe
>>
>> > there’s a reliable method for determining the locale of the data in the
>>
>> > clipboard (correct me, if I’m wrong). Not changing inputLocale to null (or
>>
>> > undefined) when data is pasted allows for the locale of pasted data to be
>>
>> > handled by the user via changing their input locale. Restated:  only the
>>
>> > user’s explicit changes to input locale (via keyboard shortcuts, IME,
>>
>> > speech/handwriting recognition tools, etc.) result in a change to
>>
>> > inputLocale.
>>
>> >
>>
>> >
>>
>> >
>>
>> > I’d imagine it somewhat like this:
>>
>> >
>>
>> >
>>
>> >
>>
>> > On the document (or arguably, the window):
>>
>> >
>>
>> >      inputLocale  of type DOMString, readonly
>>
>> >
>>
>> >           A BCP-47 language tag [2] representing the input locale as last
>>
>> > set by the user. When the underlying platform does not expose this
>>
>> > information, the value should be “Unidentified”.
>>
>> >
>>
>> >
>>
>> >
>>
>> > As a new event:
>>
>> >
>>
>> >           Type: inputLocaleChange
>>
>> >
>>
>> >           Interface: Event
>>
>> >
>>
>> >           Sync/Async:   Sync
>>
>> >
>>
>> >           Bubbles: Yes
>>
>> >
>>
>> >           Target: Element
>>
>> >
>>
>> >           Cancelable: No
>>
>> >
>>
>> >           Default action: none
>>
>> >
>>
>> >
>>
>> >
>>
>> > --Jacob
>>
>> >
>>
>> >
>>
>> >
>>
>> > [1] http://lists.w3.org/Archives/Public/www-dom/2010JulSep/0119.html
>>
>> >
>>
>> > [2] http://en.wikipedia.org/wiki/BCP_47
>>
>> >
>>
>>
>>
>
>