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.
