[Bug 23910] What's the good .key value while IME is open?

https://www.w3.org/Bugs/Public/show_bug.cgi?id=23910

Gary Kacmarcik <garykac@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |garykac@google.com

--- Comment #1 from Gary Kacmarcik <garykac@google.com> ---
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.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Tuesday, 8 April 2014 00:55:08 UTC