Re: specification of "legacy" key events

On Thu, 08 May 2008 12:05:23 +0200, Ian Hickson <ian@hixie.ch> wrote:

>> We have had requests to fire some kind of identifiable event when typing
>> occurs during IME processing for use cases like the following:
>>
>> 1) To resize an area based on user typing, even during IME entry (yes,  
>> this
>> works right, the text is in the text field even when unconfirmed..
>> 2) To have special keyboard shortcuts work in a text field even during  
>> IME entry.

As I already said, nice use cases and we should accomodate them. I think  
all UAs I tested send keyup events - perhaps that's all we need though?

> Indeed, we (Google) would very much like our scripts to be notified of
> what's going on, keyboard-wise, during IME. In particular when the user  
> is working with a contentEditable section we really need to have access  
> to
> these events so that, for example, we can, if the user so desires, cancel
> them

I think this can not be specified for the legacy key events (keydown,  
keypress) since existing IMEs and browser implementations ignore  
cancelling these events while an IME is processing the input. Firing "some  
kind of identifiable event" might be for example the input events Safari  
is currently firing, it does not have to be keydown and keypress.

> and provide our own IME implementation (which might hook into
> user-specific information that the UA might not be able to provide).

Ian, in general it's unclear to me how you see this working - if I have  
selected a specific IME and input mode to type in some text it's likely  
that this is a VERY conscious choice, and that the IME I'm using has  
learnt what words I'm more likely to want to type. (Pretty much any  
Japanese IME I've used does remember what kanji combinations I've used,  
and mobile phone IMEs are very good at re-ordering kanji options by your  
usage statistics.) I think any sort of script interference with this would  
be *extremely* annoying to me as an end user, and if you want to implement  
input method editors in JS you would be more likely to build this on top  
of an ASCII input mode anyway.

If we do want to go there, I think we should investigate specifying either  
Firefox's composition events or Safari's "input during IME composition"  
events and whether these could be made cancellable. We also need a  
developer who has worked on IME integration to confirm that the UA is  
technically able to "undo" a character that has been sent to the IME (and  
in a clean way please, not sending a backspace char or some hack like  
that!). I'm not sure if this is the case.

-- 
Hallvord R. M. Steen
Core QA JavaScript tester, Opera Software
http://www.opera.com/
Opera - simply the best Internet experience

Received on Wednesday, 14 May 2008 20:18:00 UTC