Heh, I've lost count of how many times I've written "document.onkeydown = function(e) { console.log(e.keyCode); }" to deal with this. This is probably easier, if I can remember it when I need it :)
This is just a problem with keyCodes in general. They're a very blunt tool that would useless if it weren't that there are barely any alternatives in JS.
JavaScript has absolutely massive issues with anything regarding internationalization. This is the language that shipped with a Y2K bug in 1995!
I am the author of this library. Just wanted to point out what other people have said. Using keycodes on there own is not very reliable across different keyboard layouts/international keyboards.
Mousetrap defaults to trying to use character codes whenever possible, and for keys that don't send character codes (such as arrow keys, space bar, enter, tab, etc) it falls back to using keycodes.
So it should handle all the annoying stuff,cross browser inconsistencies, etc. for you.
it would be nice if it can simultaneously display appropriate JS code to bind for a particular key. Also, if it can recognize key combos like ctrl-alt-s
Key codes are pretty good for little things, but they break down pretty quickly if you want international support. In Mathquill, we ended up just using a hidden textarea and a setTimeout, with a few hilarious hacks. The comments and commit history are worth a read: https://github.com/mathquill/mathquill/blob/dev/src/textarea...
> For browsers that generate keypress events for special keys, it is also generally true that event.keyCode will have the same value for "left-arrow" and "%", however we can usually tell which it is because event.which is zero for special keys (there are problems with this in Opera and Konqueror, see above). Versions of WebKit before 525 took a different approach. They invented unique values to return instead of ASCII codes for special keys, and returned the same value in event.keyCode, event.which, and event.charCode. The table below gives the extended ASCII codes returned by old WebKit versions, and also the ones returned in event.charCode on keydown and keyup events in Macintosh versions of IE.
DOM keycodes are kind of broken beyond repair[1]. They cannot be relied upon to determine precisely which character a user entered (even jQuery's charcode falls short here) because they do not take into account modifier keys, compositions, or locales.
The key that is being pressed should be shown on the page somewhere - though it would make it look uglier. But for a utility like this, probably won't matter all that much.
Although it is interesting to tap on random buttons to see what the results are. Some of them produce a key code but no character (SHIFT and RETURN as examples) while others produce a different character than what I tapped.
Just tossed it together rather quickly so there's probably a better way to do it.
Anyone ever noticed that the print screen key is from what I can see, the only key on a conventional qwerty keyboard that doesn't have an event code? What's the reasoning for that?
33 comments
[ 3.0 ms ] story [ 39.7 ms ] threadAnyway, upvoting because the guys behind it are awesome.
JavaScript has absolutely massive issues with anything regarding internationalization. This is the language that shipped with a Y2K bug in 1995!
Mousetrap defaults to trying to use character codes whenever possible, and for keys that don't send character codes (such as arrow keys, space bar, enter, tab, etc) it falls back to using keycodes.
So it should handle all the annoying stuff,cross browser inconsistencies, etc. for you.
edit: I am using firefox
Key combos like you describe would be handled by the shiftKey/metaKey/etc attributes of the event object provided to the event handler.
No-one listened to them.
from http://unixpapa.com/js/key.html :
> For browsers that generate keypress events for special keys, it is also generally true that event.keyCode will have the same value for "left-arrow" and "%", however we can usually tell which it is because event.which is zero for special keys (there are problems with this in Opera and Konqueror, see above). Versions of WebKit before 525 took a different approach. They invented unique values to return instead of ASCII codes for special keys, and returned the same value in event.keyCode, event.which, and event.charCode. The table below gives the extended ASCII codes returned by old WebKit versions, and also the ones returned in event.charCode on keydown and keyup events in Macintosh versions of IE.
Key combinations don't have separate codes.
In code you could listen for keydown on the code for shift, and then for the code for the other key.
[1] For a (detailed) explanation: http://unixpapa.com/js/key.html
Although it is interesting to tap on random buttons to see what the results are. Some of them produce a key code but no character (SHIFT and RETURN as examples) while others produce a different character than what I tapped.
Just tossed it together rather quickly so there's probably a better way to do it.