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

Thanks for the input, Masayuki, and apologies for the slow response.

It sounds like we would be in agreement on the following, then:
1. Add normative text explaining that content should expect that keydown/keyup events for AltGr _may_ reflect the platform-dependent mechanisms used to access the extra characters.
2. Specify that under keyboard layouts with AltGr-shifted characters on one or more keys, if the platform accesses those characters via an existing non-AltGr modifier/combination then that modifier/combination should be cleared on the keydown/keypress/keyup events, and the AltGr modifier set instead.
3. Specify that under non-AltGr layouts, or for keys which do not generate any character under the platform-specific AltGr modifier/combination, the platform-specific modifier/combination flags should be reported, rather than replacing them with AltGr.

This should meet the following requirements:
a. Content can distinguish AltGr-generated characters from Ctrl/Alt modified keys on Windows.
b. Users can still enter AltGr-shifted characters via Control+Alt+<key> if necessary.
c. Users can still access Control+Alt modified sequences, even under AltGr layouts, under Windows, provided the modified <key> would not generate a printable character.

WDYT?

I still think it would be valuable for UAs to have the option of "fixing" the keydown/keyup event sequence, but that is definitely non-trivial, and mostly serves specialist content (e.g. remote-access clients), so seems less critical to address.

Regarding "scanning" the layout, Chrome already does this whenever the active layout changes, to collate a lookup table from which to generate |key| values for subsequent events, FWIW.

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