Re: Proposal: addKeyListener and removeKeyListener Methods

Doug Schepers wrote:
> Hi, DOM3 Events fans-
>
> Since DOM3 Events now has a more robust (and standardized) keyboard 
> event model, it seemed appropriate to consider more closely how it 
> might be used.  As an input device, the keyboard is particularly 
> complicated, with many keys having dedicated functionality.  To some 
> degree, I addressed this in the description of default actions of the 
> 'keydown' event [1], but there have been many times where I wished to 
> listen only to specific keys.  It's easy enough to filter out the keys 
> using the "if...else" or "switch" statements in the event handler, but 
> it would be nice to attach different listeners to different keys to 
> dispatch to different event handlers.
>
> Thus, I've tentatively added a proposal for new 'addKeyListener' and 
> 'removeKeyListener' methods to the Event interface, which you can 
> review and comment on in the latest draft. [2]
A more generic filtering option would be better. There are events other 
than keydown that could benefit from filtering, and there are event 
properties other than keyIdentifier that need checking (especially 
modifiers in the case of keydown).

I could say more, but it would more-or-less paraphrase the event 
filtering in the XBL specification. See:

http://www.w3.org/TR/xbl/#the-handler
http://www.w3.org/TR/xbl/#registering1

And more details on event filtering:
http://www.w3.org/TR/xbl/#mouse
http://www.w3.org/TR/xbl/#key-event
http://www.w3.org/TR/xbl/#text-input
http://www.w3.org/TR/xbl/#mutation
http://www.w3.org/TR/xbl/#modifiers

A naive interface could be:
listen(in DOMStringMap filters, in EventListener listener)
unlisten(in DOMStringMap filters, in EventListener listener)

where filters can contain the following keys:
    type (required), phase, keyIdentifier, keyLocation, data, button, 
detail, attrName, attrChange, prevValue, newValue

Received on Sunday, 13 September 2009 13:02:54 UTC