Re: Proposal: addKeyListener and removeKeyListener Methods

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

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

--Jacob

Received on Monday, 14 September 2009 03:17:17 UTC