This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Except Roman character input mode of Japanese IME, non-ASCII character is inputted by a key to composition string via IME. For example, Kana input mode of Japanese IME, Hiragana or Katakana is inputted from each printable key. Similarly, a part of Hangul character (Syllable) is inputted from each printable key and composed to a Hangul character by IME. It depends on the platform and/or IME whether the keyboard layout is also changed to the actual input characters. E.g., some Japanese IMEs change keyboard layout with Kana-Lock mode on Windows, but some other Japanese IMEs do NOT change keyboard layout actually. Instead, they converts ASCII character to Kana in IME with mapping table. I believe that browser should use ASCII capable keyboard layout's value to the .key as far as possible. Then, browser behavior becomes consistent between platforms and IMEs. I think that if it's impossible especially on mobile platforms which use virtual keyboard, it's okay to use the non-ASCII character. However, at least on Desktop OSes, browsers should not depend on platform and IME. If we prefer #1 approach of bug 23909, using ASCII capable keyboard layout for computing .key value makes sense. I'd like D3E spec defines an example for this case. E.g., keydown 's' compositionstart '' compositionupdate 'と' beforeinput 'と' DOM change occurs input 'と' keyup 's'
Transcript of conversation from teleconf: garykac: Are the examples #35 and #36 in section 6.4.4 not sufficient? masayuki: it’s not enough for Kana input mode of Japanese IME and Korean IME. I’m not sure Chinese IME. FYI: Some Japanese IME changes the keyboard layout to Kana-input layout actually, but the others does not change the keyboard layout. Insted of that, they map every key input to their own Kana input layout. garykac: What would be a good example to add? (I don’t follow the ‘s’ and ‘と’ example in the bug). Ah, I think I understand now: ‘a’ = ‘ち’, ‘d’ = ‘し’ masayuki: yes, you understand correctly. garykac: OK. This sounds like a good example to include then. I’d rather just pass the value from the OS along than having to calculate something. masayuki: that may cause different behavior between Roman input mode and Kana input mode. E.g., if a web app wants to handle ‘c’ while editor doesn’t have focus, it also hadles ‘そ’ for Kana input mode. Because e.g., Kotoeri changes the keyboard layout, but ATOK doesn’t do it. I.e., in this case, only Kotoeri user cannot access the ‘c’ key handler if the web app doesn’t handle ‘そ’. garykac: Ugh. So it sounds like we don’t want to explicitly require a particular value there, but rather say that it is OS/IME specific. masayuki: On Mac OS X, Firefox referes ASCII capable keyboard layout for computing .key value. On Windows, Firefox ignores Kana Lock state for doing that. garykac: So FF always returns ‘そ’ for |key| on either platform (never ‘c’)? masayuki: No, always return ‘c’. never returns ‘そ’. garykac: I’m fine with that, but how do you know when it is safe to apply this transform? Couldn’t another keyboard layout require a different mapping? Or do you know that whenever you see ‘そ’ that it is that layout so you can safely apply the mapping? garykac: Also would that mapping apply for mobile (where you might only see the kana)? masayuki: Kana input mode is minority in Japan, therefore, even if web apps are made by Japanese people, they usually don’t test Kana input mode. Therefore, we found this problem actually and we changed our behavior for Kana input mode users :-( garykac: ^_^ That makes sense. We should make sure the spec doesn’t preclude that behavior since it sounds useful. I’m wondering if it should be *required* in the spec - it seems very specific and I don’t want to bloat the spec. masayuki: Note that compositionupdate will tells actual input character if composition actually occurs. garykac: True. People should be looking at the composition events if they want the real char intended by the user. masayuki: yes. on mobile, I’m not sure the platform limitation because I’ve never found IMEs which support Kana input mode with external USB keyboard on Android. I recommend that the Spec should append note for both implementers and authors about this issue. garykac: sounds good to me.
Summarizing the bug so far ========================== Japanese IME has KanaMode where (instead of the typical IME behavior of multiple keys being composed into a single character - like 's' + 'i' producing 'し') each key on the keyboard is associated with a character (just like a normal keyboard layout). So, 'a' produces 'ち' directly, 's' -> 'と', 'd' -> 'し', and so on. Similar to how an Arabic keyboard layout would generate key events, except that the IME generates them with composition events. Firefox has code to detect this mode and generate the ASCII key (e.g., 'a', 's' or 'd') instead of the Japanese character (e.g, 'ち', 'と' or'し'). This is to work around bugs found on websites that would (for example) check for 'a' keydown events - these sites would break when KanaMode is enabled since they would be getting 'ち' instead). This bug happens because KanaMode is not commonly used and websites (apparently) don't test against it. Thinking more about this ======================== (1) This is working around a bug in websites, and I'm not sure it makes sense to require this in the spec since it adds complexity. (2) Any website that is broken with KanaMode is also broken if the user has an Arabic (or any other non-English) keyboard. The fix above only handles the specific case for a specific mode of the Japanese IME. So it doesn't seem (to me) like the fix *really* fixes the problem - it just makes it less likely to impact users. (3) It sounds like the broken websites should really be using 'code' if they're interested in knowing which physical key was pressed. (Hard to tell without knowing more details about the broken sites.) (4) In an ideal world, I'd prefer KanaMode to return simple key events (without any composition events). Sadly, I don't think that's possible with the way IMEs are setup on the various platforms (but I'm happy to be wrong here). So, the question boils down to: Should we update the spec to allow Firefox to continue their (partial) fix for broken websites? Adding this exception to the spec will mean adding an awkward and potentially confusing paragraph (or two + an example) to an already complex spec. My sense is that we should (reluctantly) add this exception - but only because this is already shipping behavior (otherwise it wouldn't be worth considering). However, since the "fix" doesn't even really fix the problem, I'm not sure if it's worth the effort. Any further thoughts or comments on this issue?
FYI, the majority of Chinese users(it's nearly 80% of the mobile users and most PC users we are talking about) are accustomed to Pinyin Input Method, which doesn't require such kind of mapping. Of course there are other Chinese input modes similar to Kana, e.g Wubi or Bushou, but most of them were abandoned by users due to their complexity and lack of support, so I don't see a strong demand for this exception from the Chinese users.
It might be good to set "IMEKey" or something during composition if we use "DeadKey" for dead key. * Actual input character will be provided by composition events or input events. * KeyboardEvent.code might help if web apps need to distinguish keys even during composition.
(In reply to Masayuki Nakano from comment #4) > It might be good to set "IMEKey" or something during composition if we use > "DeadKey" for dead key. > > * Actual input character will be provided by composition events or input > events. > * KeyboardEvent.code might help if web apps need to distinguish keys even > during composition. Note: Bug 24044 recommends "DeadKey" for the 'key' value during a dead-key sequence. Thinking about this a bit--it makes sense to me. Given the note about how some OS's use IMEs to represent dead-keys would mean that JavaScript code might already need to have a condition that handles "DeadKey"? Rather than make them have two conditions "DeadKey" || "IMEKey", we should consider just using one, and I think I would recommend "IMEKey" be used for both to promote recognition of how the dead keys should be typical recognized. I wanted to clarify: are you suggesting having key be "IMEKey" whenever any composition is in progress, or just when KanaMode is enabled? Here's what would need to change (I think I captured everything) to make the key value "IMEKey": Example 22 - 3rd row, key becomes "DeadKey" (or "IMEKey"?) was "DeadAcute" Prose of section 6.4.3. Example 33 - (Add .code to the table too!) Event Name .key .isComposing .data Notes ----------------------------------------------------------------- 1. keydown 'DeadKey'* false Combining Circumflex Accent 2. compositionstart '' 3. compositionupdate '\u0302' 4. keyup 'DeadKey' true 5. keydown 'IMEKey' true (Typically suppressed) 6. compositionupdate 'ê' 7. compositionend 'ê' 8. keyup 'IMEKey' false Latin Small Letter E (Typically suppressed) Example 34 - (Add .code to the table too!) Event Name .key .isComposing .data Notes ----------------------------------------------------------------- 1. keydown 'DeadKey'* false Combining Circumflex Accent 2. compositionstart '' 3. compositionupdate '\u0302' 4. keyup 'DeadKey' true 5. keydown 'IMEKey' true Latin Small Letter Q (Typically suppressed) 6. compositionupdate '' 7. compositionend '' 8. keyup 'IMEKey' false (Typically suppressed) Example 35 - (Add .code to the table too!) Event Name .key .isComposing .data Notes ----------------------------------------------------------------- 1. keydown 's' false Latin Small Letter S 2. compositionstart '' 3. compositionupdate 's' 4. keyup 's' true 5. keydown 'IMEKey' true Latin Small Letter I (Typically suppressed) 6. compositionupdate 'し' 7. keyup 'IMEKey' true (Typically suppressed) 8. keydown 'Convert' true Convert (Typically suppressed) 9. compositionupdate '詩' 10. keyup 'Convert' true (Typically suppressed) 11. keydown 'Convert' true Convert (Typically suppressed) 12. compositionupdate '市' 13. keyup 'Convert' true (Typically suppressed) 14. keydown 'Accept' true Accept (Typically suppressed) 15. compositionend '市' 16. keyup 'Accept' false (Typically suppressed) Example 36 - (Add .code to the table too!) Event Name .key .isComposing .data Notes ----------------------------------------------------------------- 1. keydown 's' false Latin Small Letter S 2. compositionstart '' 3. compositionupdate 's' 4. keyup 's' true 5. keydown 'IMEKey' true Latin Small Letter I (Typically suppressed) 6. compositionupdate 'し' 7. keyup 'IMEKey' true (Typically suppressed) 8. keydown 'Convert' true Convert (Typically suppressed) 9. compositionupdate '詩' 10. keyup 'Convert' true (Typically suppressed) 11. keydown 'Convert' true Convert (Typically suppressed) 12. compositionupdate '市' 13. keyup 'Convert' true (Typically suppressed) 14. keydown 'Cancel' true Cancel (Typically suppressed) 15. compositionupdate '' 16. compositionend '' 17. keyup 'Cancel' false (Typically suppressed) WDYT?
Also, example 39.
Per our latest Telco, there doesn't seem to be agreement that the proposal made above is worthwhile, since the key events _should_ be suppressed during composition. http://www.w3.org/2014/04/23-webapps-minutes.html >> <garykac> I'm not sure what the advantage is of sending IMEKey during composition - they keyup/down events don't seem useful at that point. We recommend suppressing these events why not just require suppressing these events rather than saying that you may generate (useless) IMEKey events? It seems that if we suppress the key events, then the issues found with KanaMode are far less impactful (as the key events themselves wouldn't be dispatched to the web page). We also have .isComposing to help offer the clue that a composition is in progress. Perhaps just letting KanaMode have this particular behavior (as well as other affected languages is the right thing to do (and not attempt to special-case this in the spec).
Our current disposition is not to make a change to the spec for this issue. We reason that the sites that Firefox fixed by putting the workaround in place for Kana mode must have needed to change anyway due to browser interoperability over time. Also, since the time that this issue was filed, we have made some changes that recommend not dispatching key events during composition to avoid the general issue of giving websites intermediate key states during composition. When IMEs do not allow an implementation to suppress the key events, the isComposing attribute will be set which can also be used to filter these intermediate key event states. In this way we hope to drive more awareness of composition events and have websites defer to those events when they need the in-between key values (rather than trying to infer this via the key attribute.