Re: proposal: add input/keyboard locale to text and keyboard events

Hi, Aharon-

We discussed this in a recent telcon, and while we like the idea of 
exposing the keyboard language and see the use cases, we weren't sure 
that including that information in each event was the right approach; 
there is some question also as to how accurate and useful this will be 
in practice, for the reasons you cited before.  Considering that there 
were also legitimate concerns about privacy, we think that this needs 
more discussion before including it in a spec.

Logistically, we want to move forward to Last Call for the DOM3 Events 
spec right away; we have spent the last few months polishing up the 
existing features, rather than adding new features.

There are a couple paths forward at this point:

1) Consider including this in another spec which may be a better fit; 
there is a proposed spec which deals with keyboard state, giving content 
authors access to a list of all the keys that are currently pressed; one 
use case for this is where the keyboard is being used for non-text uses 
like game controls;

2) Raise this as a Last Call issue on the DOM3 Events spec, and have 
more discussion and endorsement on the idea during the period of the 
Last Call WD review, over the next 6 weeks; if there is sufficient 
support and consensus on the specific mechanism, I will be happy to add 
it to the spec.

I expect that you will favor the second option, because it means that 
this functionality will make it into a spec (and Recommendation) sooner, 
but I wanted to present both options to you.

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs


Aharon (Vladimir) Lanin wrote (on 8/5/10 2:47 AM):
> If the proposed (some global object).currentInputModeLocale refers to
> the speech recognition software during a speech event and to handwriting
> recognition software during a handwriting event and to the keyboard
> during a keyboard event, then what does it refer to outside the scope of
> any event, or during some event unrelated to text?
>
> 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 txt 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?
>
> Mind you, I agree that having the input locale available outside the
> scope of events would indeed be useful. 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.
>
> Aharon
>
> On Wed, Aug 4, 2010 at 9:45 PM, Olli Pettay <Olli.Pettay@helsinki.fi
> <mailto:Olli.Pettay@helsinki.fi>> wrote:
>
>     http://lists.w3.org/Archives/Public/public-i18n-core/2010JulSep/0092.html
>
>     So does the inputModeLocale (or whatever to call it) really need to be
>     in the events?
>     Could for example navigator object have .currentInputModeLocale.
>     With that a text processor could try to guess the default language even
>     before user starts to type and show that to user.
>
>     During the events dispatched because of speech input for example,
>     currentInputModeLocale would point to the "currentInputModeLocale",
>     which is the locale for speech. Same with keyboards.
>     So the main difference would be just that the default locale would be
>     available even before any input has happened.
>
>
>
>     -Olli
>
>     PS. DOM 3 Events discussion happens in www-dom@w3.org
>     <mailto:www-dom@w3.org>.
>         For some reason I can't even subscribe to
>     public-i18n-core@w3.org <mailto:public-i18n-core@w3.org>
>

Received on Friday, 27 August 2010 17:56:34 UTC