19827 2012-11-02 08:40:41 +0000 map event.key to character values of a normal QUERTY (en-US) layout 2013-08-25 18:04:10 +0000 1 1 1 Unclassified WebAppsWG HISTORICAL - DOM3 Events unspecified PC Linux RESOLVED FIXED P2 blocker --- 1 hsteen travil bugs garykac mike mounir termi1uc1 www-dom public-webapps-bugzilla oldest_to_newest 77741 0 hsteen 2012-11-02 08:40:41 +0000 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. 77742 1 hsteen 2012-11-02 08:44:06 +0000 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" http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#events-KeyboardEvent-key 77744 2 bugs 2012-11-02 09:09:10 +0000 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.) 77749 3 termi1uc1 2012-11-02 10:55:06 +0000 I created a test page to demonstrate this proposal. http://h123.ru/-/tests/KeyboardEvent/index.html 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. 92552 4 garykac 2013-08-25 18:04:10 +0000 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.