[dojo-contributors] Event handling proposal

Douglas Hays doughays at us.ibm.com
Wed Mar 16 09:49:18 EDT 2011

That's a good point about needing to call stopEvent for keydown sometimes,
and keypress others.  It is complicated.
FWIW, dijit/form/_TextBoxMixin.js tries to normalize the events:
"onkeydown", "onkeypress", "onpaste", "oncut", "oninput"
and calls onInput(e) to give that method the chance to kill the event.  It
basically assumes that printable characters
can use keypress and others can use keydown to stop the event.  It throws
in cut/paste/input events in an attempt
for user-action completeness.  The goal is that widgets that inherit from
TextBox have a standard way of dealing with keys.


  From:       Ben Lowery <blowery at dojotoolkit.org>                                                                                    
  To:         "dojo dev." <dojo-contributors at mail.dojotoolkit.org>                                                                    
  Date:       03/16/2011 09:38 AM                                                                                                     
  Subject:    Re: [dojo-contributors] Event handling proposal                                                                         
  Sent by:    dojo-contributors-bounces at mail.dojotoolkit.org                                                                          

   - keypress handling - this is moved out to dojo/_base/keypress.js as a
   custom extension/emulation event.

  Didn't quite follow the code in keypress.js, I know for IE you need to
  generate faux keypress events for non-printable characters (otherwise you
  just get a keydown event), but it looks like you are listening for
  keypress events in order to generate keypress events:

  return listen(object, "keypress", function(evt){
  // simulate a keypress event
  var faux = _synthesizeEvent(evt, {type: 'keypress', faux: true, charCode:

We might want to take this opportunity fix our key handling. I did some
poking around a bit ago, and wrote up my findings for script junkie[1]. I
think our approach of trying to rationalize key events on to the mozilla
model isn't a good way to go, it leads to too many surprises, especially
when you're trying to do something low level. A better approach would be to
expose a separate key handling abstraction, probably comparable to how
closure does it [2].

You really don't want to try to normalize onto either the IE/Webkit or the
Mozilla model. They differ on how they deal with preventing default
behavior, how repeats are handled, and a bunch of other little things.
Also, neither is backed by a standard (there is NO worthwhile standard on
how key events behave, unless you go to DOM3, and no one has bothered to
implement that in a serious manner yet).

[1] http://msdn.microsoft.com/en-us/scriptjunkie/ff928319
dojo-contributors mailing list
dojo-contributors at mail.dojotoolkit.org

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110316/2da7239d/attachment.htm 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110316/2da7239d/attachment.gif 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecblank.gif
Type: image/gif
Size: 45 bytes
Desc: not available
Url : http://mail.dojotoolkit.org/pipermail/dojo-contributors/attachments/20110316/2da7239d/attachment-0001.gif 

More information about the dojo-contributors mailing list