[w3c/uievents-key] Key specification for Mac JIS Kana / Eisu, Windows ImeOn / ImeOff, Android KANA (virtual) keys (Issue #55)

# 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 output 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

-- 
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-key/issues/55