W3C home > Mailing lists > Public > www-dom@w3.org > October to December 2012

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

From: <bugzilla@jessica.w3.org>
Date: Fri, 02 Nov 2012 08:40:41 +0000
To: www-dom@w3.org
Message-ID: <bug-19827-4009@http.www.w3.org/Bugs/Public/>

          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


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

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

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

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

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 22:37:01 UTC