W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Proposal: addKeyListener and removeKeyListener Methods

From: Doug Schepers <schepers@w3.org>
Date: Mon, 14 Sep 2009 00:05:29 -0400
Message-ID: <4AADC109.1050601@w3.org>
To: www-dom@w3.org
CC: Jacob Rossi <rossi@gatech.edu>
Hi, Jacob-

Jacob Rossi wrote (on 9/13/09 11:16 PM):
>>  >  I tend to agree with Maciej regarding getting the spec into shipping
>>  >  mode.
>>  >
>>  >  However the use cases are good. An additional use case worth
>>  >  considering is being able to filter based on character inserted into
>>  >  the DOM [or set of characters]--rather than the method used to cause
>>  >  them to appear.  Something like that could provide for a less-
>>  >  verbose DOMCharacterDataModified replacement.
>
> That's a interesting use indeed. I think also that an API for
> detecting a specific key's status is very useful. Many developers
> build elaborate state machines to keep track of which keys are
> currently down (games, as one example). As we saw with the keyboard
> event flow charts we made earlier, that's essentially an impossible
> problem to solve 100% of the time. Many errors in the state machine
> occur when the page loses focus, then the keyboard state is changed,
> and the page regains focus.
>
> So a better alternative might be an API for determining a key status:
>
> window.getKeyState(keyIdentifier as DOMString)
>
> Returns a boolean indicating if the key is down (1) or up (0).

During one of the telcons, I suggested a non-event method that would 
return a list of key identifiers that are currently being pressed... 
something like:

DOMStringList defaultView.getActiveKeys()

That way, an author could get all the keys pressed at a particular point 
in time.


> Of course we'll likely want some security restrictions (e.g., the
> method can only be called when the window has focus).
>
>>  That does sound like an interesting use case, but it also seems quite
>>  challenging to design and specify. I'm still inclined to table new
>>  features for now and get what we have wrapped up quickly. Once DOM3EV
>>  is in CR, we can start work on DOM4EV.
>
> Yes, I agree. So perhaps add my above suggestion to the DOM4EV wish list. :-)

I've started a wiki page to record these ideas:
  http://www.w3.org/2008/webapps/wiki/DOM_Use_Cases_and_Requirements

Regards-
-Doug Schepers
W3C Team Contact, SVG and WebApps WGs
Received on Monday, 14 September 2009 04:05:39 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT