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

On 20 September 2017 at 03:06, Masayuki Nakano <notifications@github.com>
wrote:

> 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.
>
My point is that the spec should explicitly mention that the applications
cannot assume a simple sequence of keydown/keyup events for AltGraph, in
general, across all platforms.

> 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.
>
If the Ctrl+Alt+<key> sequence leads to a printable character being
generated, then Ctrl+Alt should be cleared, and AltGr set, so that content
can "see" that the character was generated via AltGr.

If Ctrl+Alt+<key> does not lead to a printable character then leave
Ctrl+Alt modifiers set in the event.

> 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.
>
Yes, that would be a down-side of this approach. Remember that if content
actually expects an AltGr modifier to be set on those events then it is out
of luck on one of the reduce-size keyboards you mentioned, that don't
actually have a physical AltGr key.

An alternative would be to allow both explicit AltGr key handling and
Ctrl+Alt+<key> that generates a printable key, so that:

1. If you press AltGr on a keyboard with a physical AltGr key then the UA
*should* set the AltGr modifier, and clear any platform-specific modifiers
like Ctrl+Alt, on subsequent events.
2. If you press Ctrl+Alt (or some other platform-specific combination) to
mimic AltGr, and the result is a printable character then the
keydown/keypress/keyup for the character key should have AltGr, rather than
the other modifiers.

This would allow UAs to support use-cases served by AltGr as a general
modifier, while also allowing it to work sensibly when synthesized e.g. via
Ctrl+Alt.

> 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.
>
We've been focused on the Windows case in our implementation so far;
performance for that seems to be OK, since we're only scanning the keyboard
on the first input event after a layout switch.  But yes, we should avoid
requiring behaviour that can't be implemented without potentially expensive
scanning processes.

For platforms which usually run with IME input, I'm not sure that this
problem applies - the extended Latin-1 characters, for example, will
typically be accessed directly via long-press in the IME rather than via
setting a virtual modifier.

> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <https://github.com/w3c/uievents/issues/147#issuecomment-330807122>, or mute
> the thread
> <https://github.com/notifications/unsubscribe-auth/AcZxkrQzRFXTkj9Mwc96ObCWdsvqxgi2ks5skOOzgaJpZM4OKABk>
> .
>


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