W3C home > Mailing lists > Public > public-webapi@w3.org > August 2007

Re: DOM3 Key events

From: Oliver Hunt <oliver@apple.com>
Date: Wed, 1 Aug 2007 20:41:03 -0700
Cc: Web API public <public-webapi@w3.org>
Message-Id: <C7A2063B-242E-4F4C-A16D-688D94473094@apple.com>
To: Doug Schepers <schepers@w3.org>

> 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
>
Received on Thursday, 2 August 2007 03:41:19 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:58 GMT