Re: [w3c/uievents] Add specification for AltGraph key & modifier behaviour (#147)

Re modifier flags: I've prototyped code to disambiguate AltGr from Ctrl+Alt - I was concerned about the issue of confusion between Ctrl followed by Alt, and a single AltGr, and about the risk of content which actually needs to "see" Ctrl+Alt no longer being usable. The prototype basically:

- Scans the keyboard layout to establish whether it uses AltGraph (i.e. does Ctrl+Alt+<key> generate a character for any value of <key>?).
- Iff layout has AltGraph then:
  - Maintain an internal flag, ignoreLeftControl.
  - Set that flag depending on the precise order of Control and Alt WM_KEYDOWN events received.

This approach treats Ctrl+Alt as Ctrl+Alt, and only the specific sequence of keydown-ControlLeft followed by keydown-AltRight triggers AltGraph. The user can still Ctrl-modify an AltGraph-modified key by pressing e.g. ControlLeft after pressing AltGraph - we can spot that case because Windows sends the WM_KEYDOWN event even though the key is logically already "down".

This prototype works for me, but the state-machine is fiddly, so we should definitely consider more straightforward options, such as always treating Ctrl+Alt as AltGraph, if we're confident they won't break content on Windows.

Re the event sequence: It's possible to "hold" the keydown-ControlLeft and not dispatch it to content if it turns out to be AltGr, as part of the logic I've prototyped (see above), but as well as adding complexity, is there a risk that existing content relies on "seeing" both events for AltGr?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/w3c/uievents/issues/147#issuecomment-312312725