w3c/uievents-key

Mac keyboards other than US are unrepresented in the spec

Opened this issue · 1 comments

ak0rz commented

The only keyboard is present in the spec now is Apple US English layout, but there is a whole bunch of different keyboards in Mac world that is tightly coupled with mac OS keycodes implementation.

Just a few for a reference:

US English (currently considered in spec as Apple-wide keyboard)
US English

British English (note that Backquote keycap is located completely different from any other keyboard in spec)
image

Japanese (numeric row differs significantly from Japanese keyboard described in spec)
image

This differences already presented some implicit implementation details in Chromium and Firefox that behaves differently from what end-users see on their Apple keyboard keycaps and differs from Safari implementation (see https://bugs.chromium.org/p/chromium/issues/detail?id=1296783, https://bugzilla.mozilla.org/show_bug.cgi?id=1263302)

Maybe we can revise a spec so it would clarify behaviour on mac OS browsers?

Thanks!

Enumerating all of the various Apple keyboards is beyond the scope of the spec, and the one example in the spec was meant to be representative (since it introduces keys that are specific to Apple keyboards).

Note that we have a similar issue with laptop keyboards - there are many variations where manufacturers place standard keys in new locations. But we don't include them in the spec

The only time is makes sense to include a new layout in the spec is when there is a new key that is introduced that doesn't exist on other keyboards. Simply having the standard keys in a different configuration is something we don't attempt to track.

For example, the main part of the British English keyboard you give above is basically a standard 102-layout. The key with the `~ label should have a code of IntlBackslash because of its position, even though the key attribute would be "`" or "~".

Similarly for the Japanese keyboard where all the number keys are shifted. The code attribute will indicate the key's physical position (thus, the "1" key will have a code of Backquote, the "2" key will have a code of Digit1, ...).

The one issue you mention relating to certain Apple keyboards mis-handling Backquote and IntlBackslash is a longstanding issue with these keyboards that was thought to be fixed (perhaps only partially?). There was reason to suspect a hardware problem, and it's possible that Apple fixed the hardware issue so that the code fix in the browser is no longer needed.

If it ends up that the bug cannot be fixed in the browsers, then we should consider adding a note (to the uievents-code spec) mentioning the issue.