- From: Jacob Rossi <rossi@gatech.edu>
- Date: Mon, 14 Sep 2009 00:21:03 -0400
- To: Doug Schepers <schepers@w3.org>
- Cc: www-dom@w3.org
On Mon, Sep 14, 2009 at 12:05 AM, Doug Schepers <schepers@w3.org> wrote: > 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. Ah yes, I remember that now. Your method solves my "state machine" scenario better, I think. --Jacob On Mon, Sep 14, 2009 at 12:05 AM, Doug Schepers <schepers@w3.org> wrote: > 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:22:06 UTC