> 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
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.