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.
Comments
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...
IMO, this alone is something that the W3C or WHATWG realy needs to deal with. We have cooperation now. Cooperation on keycodes would help everyone.
They already did: http://www.w3.org/TR/DOM-Level-3-Events/#keys-keyvalues
No-one listened to them.
What a tragedy. :(
The best part is that keys that don't produce text input have codes on keypress that are indistinguishable from other keys.
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.