- From: Maciej Stachowiak <mjs@apple.com>
- Date: Mon, 14 Sep 2009 01:27:04 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: www-dom@w3.org, Jacob Rossi <rossi@gatech.edu>
On Sep 13, 2009, at 9:05 PM, Doug Schepers 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. Is this actually implementable standard OS APIs on popular platforms (I suspect maybe not)? Is there a use case for querying at a time that's *not* a state change? Regards, Maciej
Received on Monday, 14 September 2009 08:27:46 UTC