Re: Proposal: addKeyListener and removeKeyListener Methods

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?


Received on Monday, 14 September 2009 08:27:46 UTC