w3c/uievents-key

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

Opened this issue · 4 comments

gsittyz commented

Problem

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

  • Mac JIS Kana / Eisu and
  • Windows ImeOn / ImeOff (virtual) keys.

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
  • from KEYCODE_KANA / kVk_JIS_Kana / VK_IME_ON to Hiragana and
  • from KEYCODE_EISU / kVk_JIS_Eisu / VK_IME_OFF to Eisu.

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,

  • Mac JIS Kana / Eisu corresponds to kVK_JIS_Kana / kVK_JIS_Eisu
  • Windows ImeOn / ImeOff correspond to VK_IME_ON, VK_IME_OFF respectively.

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

  • Kana key: No response (Chrome*), KanjiMode (Firefox), [Space] (Safari*)
  • Eisu key: No response (Chrome*), Eisu (Firefox), [Space] (Safari*)

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

  • Android KEYCODE_KANA ← Linux Keycode 122 KEY_HANGEUL ← HID Usage Lang1
  • Mac kVk_JIS_Kana ← HID Usage Lang1
  • Windows VK_IME_ON ← HID Usage Lang1

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,

  • Android KEYCODE_EISU← Linux Keycode 123 KEY_HANJA ← HID Usage Lang2
  • Mac kVk_JIS_Eisu ← HID Usage Lang2
  • Windows VK_IME_OFF ← HID Usage Lang2
marcoscaceres commented

@garykac, would this affect us going to CR?

garykac commented

@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

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

masayuki-nakano commented

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