According to the spec as it stands, if there is an input method
editor, it happens after this sequence, which should look something
like this (note that the current spec doesn't have keypress, so I
omitted it here):
keydown -> keyup -> [IME/textInput]
Assuming that we fit keypress in there, does this cause any problems
for any browser?
Finally, we discussed the IME more extensively offlist... maybe
you'd like to share your opinions about how/whether/where this
should be specified?
I am concerned about the belief the IM behaviour should happen after
DOM keyevents, there are a few reasons for this:
* non-IM aware sites could easily unintentionally and unnecessarily
cause IMs to not work correctly or at all
* why would a keyup come prior to textInput? pressing and holding a
key does not trigger a keyup, but does generate input. Why would
using an IM change this?
* IMs vary in expected behaviour, typing enter to confirm when
using a korean IM for example will send a keydown/press/input/up set
in addition to confirming the composition, whereas the same key using
a Japanese IM would be consumed by the IM, resulting in the keydown:
229/keyup pairing given to key events that happen during composition
events
* The icky implementation arguments:
* The windows IME API would make such a model difficult (though
not impossible), as it intercepts events fairly early
* Tying textInput to keyup, will cause many mighty problems, eg.
what should be entered if I go 'a'-down, 'b'-down, 'c'-down, 'b'-up,
'c'-up, 'a'-up? textInput (if fired) should always occur after the
keydown/press
The model used by IE and WebKit is
{composition starts} ->keydown:229->keyup:realKeyCode->{composition
changed}->keydown:229->keyup:realKeyCode->{composition confirmed/
cancelled/etc}->keydown:229->keyup:realKeyCode
where {..} is something that has happened for which there is no DOM
event.
Are there any Firefox/Opera/IE people on this list who have comments?
Cheers,
Oliver
Regards-
-Doug Schepers
W3C Staff Contact, SVG, CDF, and WebAPI
