- From: Travis Leithead <travil@windows.microsoft.com>
- Date: Thu, 21 Feb 2008 13:09:46 -0800
- To: Doug Schepers <schepers@w3.org>
- CC: "public-webapi@w3.org" <public-webapi@w3.org>
- Message-ID: <937543397460F840810FA27D2922880F5BBEBD30DC@NA-EXMSG-W602.wingroup.windeploy.ntd>
I'd like to propose a discussion about the handling of the ALT + key combination that will hopefully end in a normative requirement. In observing IE as well as other browsers, there is "good" x-browser consistency between the handling of ALT and pressing a modifier key. While the browsers are mostly consistent, they do so in a way that is not very reliable for web developers because key down/key up pairs are often not respected (key events get dropped in some scenarios). I've identified the following scenarios that we can discuss: Scenarios for ALT handling where the key combination is not a 'browser-reserved' key: (Using 'X' which is a non-reserved accelerator key-at least in IE/Firefox3.) 1. Scenario 1: down ALT, down x, up ALT, up x 2. Scenario 2: down ALT, down x, up x, up ALT 3. Scenario 4: down ALT, up ALT, down ALT, down x, up ALT, up x 4. Scenario 5: down ALT, up ALT, down ALT, down x, up x, up ALT In each of these scenarios, an ALT key up or down event is lost, resulting in an inconsistent pairing of down/up events for the web developer. When handing scenarios for "browser-reserved" accelerator keys, more key events are lost (including the simple ALT down/up pair repeated twice). It would be nice to specify (perhaps in an appendix) the behavior of browser-reserved accelerator key combinations and what should be expected. To help push the discussion along, I would like to propose two potential ideas (one is more drastic than the other): 1. Create a requirement that browsers emit proper ALT key sequences (up/down pairs) to the web page unless focus has shifted out of the web page itself-here we would need to try to define where to draw the line of when ALT is in focus and when it is not in focus related to browser-reserved accelerator actions. 2. Remove the emission of modifier key (e.g., Shift/Alt/etc.) events from the key identifiers set. Thus, pressing ALT (for example) would not emit any keyboard events until a corresponding key was pressed. The KeyboardEvent interface will continue to support the Boolean modifier key flags so that distinctions between a key + a modifier can be made by the web developer, but this will cut back and the number of events raised and eliminate the out-of-order key event problems (ALT down > key down > ALT up > Key up versus ALT down > key down > key up > ALT up). Of course, a side effect is that this outcome will also effectively remove the detection of single modifier key presses for use in web applications.
Received on Thursday, 21 February 2008 21:09:31 UTC