Re: Issue Request for DOM L3 Events

I think it's probably worth pointing out that the special handling of  
ALT is specific to Windows as ALT is used to activate menus, this does  
not effect MacOS, and may or may not effect the various linux browsers  
(i honestly have no idea what they do and don't have a linux system to  
test on).

That said my (brief) testing of Safari for Windows shows that Safari  
correctly pair ALT up/down in all of the scenarios below.  The  
testcase I used is at http://nerget.com/tests/input-testcase.html

--Oliver

On Feb 21, 2008, at 1:09 PM, Travis Leithead wrote:

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