Bug 19827 - map event.key to character values of a normal QUERTY (en-US) layout
Summary: map event.key to character values of a normal QUERTY (en-US) layout
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - DOM3 Events (show other bugs)
Version: unspecified
Hardware: PC Linux
: P2 blocker
Target Milestone: ---
Assignee: Travis Leithead [MSFT]
QA Contact: public-webapps-bugzilla
Depends on:
Reported: 2012-11-02 08:40 UTC by Hallvord R. M. Steen
Modified: 2013-08-25 18:04 UTC (History)
6 users (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Hallvord R. M. Steen 2012-11-02 08:40:41 UTC

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.
Comment 1 Hallvord R. M. Steen 2012-11-02 08:44:06 UTC
One example of the "aliasing" is where the spec describes event.key as follows: "If the value is has a printed representation, it must match the value of the KeyboardEvent.char attribute"

Comment 2 Olli Pettay 2012-11-02 09:09:10 UTC
Don't understand where you get the event.key == 1 part.

Also, if user is using different locale, should it be expected that ctrl+1 in that locale maps to the
thing web pages tries to handle.
(Perhaps I'm missing something here.)
Comment 3 Egor Khalimonenko 2012-11-02 10:55:06 UTC
I created a test page to demonstrate this proposal.


It using my polyfill that in [working in progress] status, so it has a few bugs and not working in old IE (lt 9).

Note: If you have problems in Opera, turn off "output" option in "Options" section.
Comment 4 Gary Kacmarcik 2013-08-25 18:04:10 UTC
The DOM3 spec has changed considerably since this bug was filed and we're addressing the problems stated here in the following ways:

The 'char' attribute has been removed since it was only used by the deprecated keypress event.

We have introduced a 'code' attribute in the UI Events spec to identify individual keys. This attribute will allow JS authors to check for a specific key press without needing to worry about the current keyboard locale.