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.