Bugzilla – Bug 19827
map event.key to character values of a normal QUERTY (en-US) layout
Last modified: 2013-08-25 18:04:10 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]-, 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.
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"
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.)
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.
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.