W3C home > Mailing lists > Public > www-dom@w3.org > July to September 2009

Re: Proposal: addKeyListener and removeKeyListener Methods

From: Jacob Rossi <rossi@gatech.edu>
Date: Mon, 14 Sep 2009 00:21:03 -0400
Message-ID: <b1dbfad70909132121h86151cat533a5f7a7fc6d8a5@mail.gmail.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 22 June 2012 06:14:03 GMT