Non-ASCII layouts should be mapped according to the US keyboard

[tszynalski]

If the current keyboard layout is not ASCII-capable, the spec says that KeyboardMap should reflect the "highest-priority ASCII-capable layout".

This is not a good solution for three reasons:

You shouldn't rely on the concept of "highest priority ASCII-capable layout". On MacOS, layouts ("input sources") are always listed in a predefined order. The user cannot change that order. It therefore does not reflect user preference. If a Russian user has installed e.g. German, that layout will always be listed higher than US English, with serious consequences to KeyboardMap (e.g. Z identified as Y and vice versa). On MacOS, layouts cannot be taken as a priority list. The only meaningful category is the current layout. As for the other installed layouts, although the OS displays them as a list in a menu, they are best conceptualized as a set, with no highest priority layout among them.

Even if the concept of "highest priority ASCII-capable layout" made sense on all platforms, it would not be a good idea to use that layout for KeyboardMap. Why? Because, as is correctly noted in the introduction to the spec, when giving the user shortcut instructions, we want to refer to whatever is printed on the keycap. As it happens, all the non-Latin keyboards I've checked have US-English QWERTY characters on their keycaps in addition to their national characters. For example, a Ю key on a Russian keyboard will always have "[" (left bracket) printed on it as well. I believe this is the case at least for Russian, Greek, Thai, Japanese, Arabic and InScript (India). (Google queries like "Russian Apple/Microsoft keyboard" and try to find a non-Latin keyboard which doesn't also have the US layout on it.) Many (sometimes most?) people in those markets also use non-localized US-English keyboards. For example, try to find a non-US-English keyboard on this Indian classifieds site.

Therefore, a very reliable way to get "what's on the keycap" is to spec KeyboardMap.get() to return the character which is typed with the current physical key on a US keyboard. If there are any exceptions (non-Latin keyboards which use something else than US-QWERTY as their "Latin layer"), they can be handled on a case-by-case basis.

To further illustrate why this is better than the current spec, let's suppose a Russian user with a Russian keyboard has installed a German layout (maybe they need to write in German from time to time). If they don't have "US English" installed, or if German is listed higher than "US English" in Windows (both of which are possible), KeyboardMap will return results based on the German layout. So a page may instruct the user to press Z (suppose the page wants [KeyY]), but if the user presses the key with the label Z, it won't work! And the user won't know why. When I was testing KeyboardMap on a Russian layout, and it started returning French letters, I thought it was a bug! What does French have to do with Russian? I had to re-read the spec to figure it out.

Generally speaking, UI behavior should not depend on hidden stuff. Although it may be assumed that a user knows what their "active" keyboard layout is (an optimistic assumption in itself), they probably don't think of all their installed layouts as a "priority list". In normal usage, the only thing that matters is what the active layout is and what other layouts are available. I have a lot of layouts installed, and I've never paid attention to what their order is. If you asked me right now, I couldn't tell you. I just pick the right one from a list when I need it. Moreover, a user may be on someone else's system and not know what layouts are even installed. Understanding shortcuts in your Web apps should not require awareness of such internals.

What happens if a Russian or Greek user only has their national layout, but no ASCII-capable layout installed? The spec says that their active (non-ASCII) layout should be used. This would result in very unusual-looking shortcut hints, e.g. "Alt+й", which is bad in itself, but even worse, it would mean that a web page would no longer be able to understand that the user pressed P (for Print), for example. (You could work around it by using deprecated properties like .keyCode or detecting the non-ASCII layout and working out the US key value from KeyboardEvent.code.)