Re: Proposal: addKeyListener and removeKeyListener Methods

On Sep 13, 2009, at 8:16 PM, Jacob Rossi wrote:

>>> 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).
>
> Of course we'll likely want some security restrictions (e.g., the
> method can only be called when the window has focus).

Offhand, I'm not confident that this method is implementable on all  
popular platforms. The operating system delivers key events, I'm not  
sure it allows inquiries about the state of arbitrary keys, or even  
tracks this state.

>
>>
>> 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. :-)

Should we start a wiki page?

  - Maciej

Received on Monday, 14 September 2009 08:26:03 UTC