DOM3 Key events

Hi all,
   Recently Doug Schepers contacted the Apple WebKit team for  
feedback on the DOM3 key event model (http://www.w3.org/TR/DOM- 
Level-3-Events/keyset.html), and after some discussion asked if i  
could bring some of the details into a public thread.

While it is good to see work being done to define the behaviour of  
key events there are a couple of points that we find to be cause for  
concern:
   * The behaviour and interaction (and existence) of a keypress  
event is completely absent.  While the keypress events are (to a  
greater or lesser extent) evil, they are used extensively on many  
websites, and are supported by all major browsers, so not defining  
behaviour will leave us trapped in the awful quagmire of  
incompatibility that already exists.
   * Defining IME composition events is an incredibly good plan,  
however I am concerned that overloading the meaning of keydown/up  
events will lead to awkward bugs on sites that do not account for the  
existence of IMs.  There are many sites that already treat the  
keydown event as being an appropriate time to process input, and  
subsequently break under IMs unless the event model is very careful,  
and sending full strings to indicate composition events seems likely  
to cause a variety of annoying bugs to users of IMs.

Anyhoo, just for reference the WebKit key press handling is  
(approximately) as follows:

function handleKeyEvent(event) {
     if (event.isKeyUpEvent) {
         // Fire a DOM KeyUp event
         fireKeyUpEvent(event);
         return;
     }

     // We need to call the input method now as the our behaviour  
changes according to whether
     // the event was handled by the Input Method
     if (inputMethod.handleEvent(event)) {
         // The event was handled by the Input Method, if the IM  
would insert/change the current composition as a result
         // of this event then the change has *already* happened
         // A number of sites break under IMs if we just send the  
correct keyCode for the keyDown for an IM handled event
         // So we set the keyCode to 229, which matches IE :-/
         event.keyCode = 229;
         // Fire a DOM keydown event
         fireKeyDownEvent(event);
         return;
     }

     // Even though the IM has not "handled" the event the content of  
the text region may have
     // changed (eg. confirmation of a composition with various  
Korean IMs)
     bool defaultHandled = fireKeyDownEvent(event);
     defaultHandled = fireKeyPressEvent(event) || defaultHandled;
     if (!defaultHandled)
         fireTextInputEvent(event);
}

This behaviour is not something that should be used to standardise on  
as it has been designed with the goal of website compatibility rather  
than to be "nice".

Important things to note:
  * preventDefault on KeyDown will *not* prevent KeyPress events from  
being fired (this matches Firefox behaviour, and is needed for a  
couple of sites)
  * preventDefault on KeyDown *or*KeyPress will prevent the TextInput  
event, eg. no text will be inserted
  * autorepeat keys trigger keydown and keypress events (otherwise we  
break sites that expect keydown for all keyevents)
  * KeyPress and TextInput events are *not* fired if an Input Method  
has handled the event
  * the keyCode for a KeyDown event that has been handled by the  
Input Method will be 229, this is needed to not break a number of  
sites -- might be reducible to only mask the keycode for control  
keys, but that's difficult to verify.  People do really stupid things  
on keydown.
  * the Input Method *may* have side effects that occur before any  
key event has been fired.  This is kind of icky, but matches IE  
behaviour, but i strongly doubt any sites exist that depend on this  
behaviour.

--Oliver

Received on Wednesday, 1 August 2007 21:57:39 UTC