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