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.
JavaScript has absolutely massive issues with anything regarding internationalization. This is the language that shipped with a Y2K bug in 1995!
Anyway, upvoting because the guys behind it are awesome.
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 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.
Key combos like you describe would be handled by the shiftKey/metaKey/etc attributes of the event object provided to the event handler.
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.
[1] For a (detailed) explanation: http://unixpapa.com/js/key.html
