Hallvord R. M. Steen wrote:
RELATIONSHIP BETWEEN EVENT TYPES
There are two types of key events:
* Hardware reference events. The keydown and keyup events report that a
key was pressed down and released. These events include keyboard
reference information but do not confirm what character(s) if any will
be inserted. Keyboard reference codes are hardware-, software-, locale-
and system-dependent, but implementations should map as many keys as
possible to virtual key codes as defined below.
* Text insertion events. The keypress and textInput events include
complete information about the character the input is generating, if
any, taking into account shift states, previous dead keys and other
contextual information required to decide what character will be
inserted by a key press. The textInput event also shows what
character(s) were generated by an active input method editor. The
keypress event MUST NOT fire when an IME is processing the input for
conversion.
textInput isn't DOM0 event, right? It is (or will be defined) in DOM 3
Events.
All keys except dead keys fire the hardware reference events.
...
> The first time a dead key is pressed fires no
events at all.
Based on testing on Windows Vista, all browsers do generate keydown/up
also with dead keys (at least with ¨ and ´). And pressing space creates
then keydown/keypress/keyup (and input, except not in IE)
On Linux things are different. FF3 fires only keyup (and input event
after space), Opera doesn't fire anything, not even input.
So, I think we should follow the event handling which browsers have on
Windows.
* If the key does not cause text input and is not the Escape key (i.e.
if the key is not is an alphanumerical key, a punctuation key, a
repeated press of a dead key or the Escape key), terminate this algorithm.
Why this behavior? Opera and FF do dispatch keypress in many other cases
too. (And Safari doesn't dispatch with ESC).
-Olli
