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

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

Hmm, I don't understand what you meant. `AltGraph` keydown/keyup events may not be fired with platform limitation (e.g., macOS), but `AltGraph` state could be set to InputEvents.

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

I don't understand this well. Did you mean that even when Ctrl+Alt is pressed on Windows with keyboard layouts which has AltGr key, then, `Control` and `Alt` modifiers should be cleared and `AltGraph` is set? If so, I agree with that.

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

Hmm, so, did you mean that if AltGr key doesn't exist as an independent key  (like Windows), only when KeyboardEvent inputs one or more characters, `AltGraph` should be set but otherwise, should be set only actual modifiers (e.g., Ctrl + Alt)? If so, I agree with that. However, it'll never set `AltGraph` state to other InputEvents like MouseEvent on Windows. But I have no idea how that causes problem for web developers.

> 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+ if necessary.
> c. Users can still access Control+Alt modified sequences, even under AltGr layouts, under Windows, provided the modified would not generate a printable character.

Agree.

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

Gecko does it only on Windows but not so on the other platforms. I don't know the performance of macOS and GTK is enough fast. I have no idea about Android since it provides virtual keyboard with IME.

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