[Bug 19827] New: map event.key to character values of a normal QUERTY (en-US) layout

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

          Priority: P2
            Bug ID: 19827
                CC: mike@w3.org, www-dom@w3.org
          Assignee: schepers@w3.org
           Summary: map event.key to character values of a normal QUERTY
                    (en-US) layout
        QA Contact: public-webapps-bugzilla@w3.org
          Severity: blocker
    Classification: Unclassified
                OS: Linux
          Reporter: hallvord@opera.com
          Hardware: PC
            Status: NEW
           Version: unspecified
         Component: DOM3 Events
           Product: WebAppsWG

http://lists.w3.org/Archives/Public/public-webapps/2012OctDec/0319.html

I've received feedback from JS authors trying to code for the new DOM3 Events
implementation. According to this feedback, although the new spec attempts to
be more i18n-friendly it is actually a step backwards compared to the
event.keyCode model:

If, for example, you would like to do something when the user presses
[Ctrl]-[1], under the old keyCode model you could write this in a keydown
handler:

if(event.ctrlKey && event.keyCode == 49)

while if you want to use the new implementation you will have to do something
like

if(event.ctrlKey && ( event.key == 1 || event.key == '&' || event.key == '1' ))

and possibly even more variations, depending on what locales you want to
support. (That's three checks for English ASCII, French AZERTY and Japanese
hiragana "wide character form" layouts respectively - I don't know of other
locales that assign other character values to this key but they might exist). 

Obviously, this makes it orders of magniture harder to write cross-locale
applications and places a large burden of complexity on JS authors.

In the current spec, event.key and event.char are actually aliases of each
other for most keys on the keyboard: if the key you press doesn't have a "key
name" string, event.key and event.char are spec'ed as being the same value.

This "aliasing" doesn't really add up to a clear concept. If two properties
have the same value almost always, why do we add *two* new properties in the
first place?

This is also the underlying cause for other reported problems with the new
model, like the inability to match [Shift]-[A] keydown/up events because
event.key might be a in keydown but A in keyup or vice versa.

I would like the "story" of event.char and event.key to be that event.char
describes the generated character (if any) in its
shifted/unshifted/modified/localized glory while event.key describes the key
(perhaps on a best-effort basis, but in a way that is at least as stable and
usable as event.keyCode).

Hence, what I think would be most usable in the real world would be making
event.key a mapping back to un-shifted character values of a normal QUERTY
(en-US) layout. Authors are asking for stable reference values for identifying
keys, and that's the most stable and widely known reference keyboard layout.

Doing this will resolve https://www.w3.org/Bugs/Public/show_bug.cgi?id=18341
too. 

https://www.w3.org/Bugs/Public/show_bug.cgi?id=18867 is orthogonal. Doing what
both this bug and 18867 suggests would imply some information loss (you will no
longer be able to see the localized / modified character in a "shortcut"-type
keypress like [Ctrl]-[A]), so that bug may have to be reconsidered if we go
with this one.

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

Received on Friday, 2 November 2012 08:40:58 UTC