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

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

            Bug ID: 23910
           Summary: What's the good .key value while IME is open?
           Product: WebAppsWG
           Version: unspecified
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DOM3 Events
          Assignee: travil@microsoft.com
          Reporter: masayuki@d-toybox.com
        QA Contact: public-webapps-bugzilla@w3.org
                CC: mike@w3.org, www-dom@w3.org

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'

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Monday, 25 November 2013 09:30:47 UTC