search

w3c / uievents-key

UI Events KeyboardEvents key Values
https://w3c.github.io/uievents-key/
Other
15 stars 16 forks source link

Key mapping specification for Mac JIS Kana / Eisu, Windows ImeOn / ImeOff, Android KANA (virtual) keys #55

Open gsittyz opened 2 years ago

gsittyz commented 2 years ago

Problem

The W3C recommendation currently does not explain clearly to indicate key mapping for

Also, the current key map implementation might lead to key overlap in Windows.

Proposed solution

I prefer solution 1 because it separates functions clearly, but 2 might be better for compatibility. 1) Add new ​named key attribute values such as ImeOn / ImeOff to avoid any overlaps. 2) Add clear explanation to Hiragana and Eisu to indicate mappings

This mapping accepts overlaps on Hiragana, because the function of Lang1-VK_IME_ON is similar to that of KanaMode- VK_OEM_COPY=VK_DBE_HIRAGANA in WIndows.

See: https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/keyboard-japan-ime

Detailed Explanation

In the native virtual keys,

Unclear W3C specification leads to confusion in browser KeyboardEvent.key implementations:

* Chrome and Safari outputs seem to be a bug and I partially work on this issue.

Windows ImeOn / ImeOff has been recently introduced, and AFAIK there is little Windows browser implementation for them currently.

They function like Mac Kana / Eisu and share the same HID usage name. *If we apply this Mac Firefox mapping to Windows, we cannot distinguish VK_KANJI () and VK_IME_ON based only on KeyboardEvent.key, which is not straightforward.* \ KanjiMode corresponds to VK_KANJI in Windows.

Definition in Java SE6

java.awt.event.KeyEvent, which some named key attribute values comes from, defines Macintosh Kana / Eisu separately (VK_JAPANESE_HIRAGANA, VK_JAPANESE_ROMAN) in addition to japanese 106 key.

https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/java/awt/event/KeyEvent.java

HID - Virtual Key Relationship:

30 points out that KanjiMode is suitable for KEYCODE_KANA, but Lang1 actually does not generate VK_KANJI in Windows.

https://cs.android.com/android/platform/superproject/+/master:device/google/atv/Generic.kl https://source.android.google.cn/devices/input/keyboard-devices https://docs.microsoft.com/en-us/windows-hardware/design/component-guidelines/keyboard-japan-ime https://developer.apple.com/documentation/uikit/uikeyboardhidusage/uikeyboardhidusagekeyboardlang1

Similarly,

marcoscaceres commented 2 years ago

@garykac, would this affect us going to CR?

garykac commented 2 years ago

@masayuki-nakano for comments on this since he is more familiar with IMEs and the Firefox implementation, which would be most impacted by any change.

siusin commented 1 year ago

@masayuki-nakano @garykac could you follow up on this issue? Thank you.

masayuki-nakano commented 1 year ago

Oh, sorry for the long delay to reply. When I was implementing KeyboardEvent.key in Gecko, I requested that there should be key values for Kana and Eisu keys of Mac. Then, probably I got a reply for that and I mapped them to Kana and Eisu. https://searchfox.org/mozilla-central/rev/ca52886e3b6051ca87861567e0c7628915f68780/widget/NativeKeyToDOMKeyName.h#552,577

Windows ImeOn / ImeOff has been recently introduced, and AFAIK there is little Windows browser implementation for them currently.

Yes, it is. They were introduced 2004 (Win 10 1903). Therefore, most users have already started using newer Windows than it. (FYI: Firefox still supports alter Windows too, though.)

If we apply this Mac Firefox mapping to Windows, we cannot distinguish VK_KANJI (*) and VK_IME_ON based only on KeyboardEvent.key, which is not straightforward.

Right. On the other hand, some 3rd party IMEs seem to handle the IME specific keys before native applications. Therefore, their .key value may become Process. So, I'm not sure whether these keys are actually usable for web apps...