Detecting keystrokes

Detecting the user's keystrokes turns out to be a rather specialised branch of event handling. This page details some of the more obnoxious problems, and gives the inevitable compatibility table.

The first problem is that there is no standard for key events; the specification says:

An event module designed for use with keyboard input devices will be included in a later version of the DOM specification.

As we all know, browser vendors start experimenting when there's no official standard, and these experiments, though occasionally useful, also cause incompatibilities. The key events are no exception: there are currently two properties that give information about the pressed keys, and although there's some justification for this duplication, not all browsers support them in the same way.

In addition, there are a few important differences between the keydown and keyup events on one hand, and the keypress event on the other.

Finally, there are important differences between Windows and Mac. In general, detecting keys on Mac is much, much more difficult than on Windows.

keyCode and charCode

The two properties are keyCode and charCode. Put (too) simply, keyCode says something about the actual keyboard key the user pressed, while charCode gives the ASCII value of the resulting character. These bits of information need not be the same; for instance, a lower case 'a' and an upper case 'A' have the same keyCode, because the user presses the same key, but a different charCode because the resulting character is different.

Explorer and Opera do not support charCode. However, they give the character information in keyCode, but only onkeypress. Onkeydown and -up keyCode contains key information.

Alphanumeric keys

Let's start with a simple example. The lower case 'a' has ASCII value 97, while the upper case 'A' has ASCII value 65. In both cases the user presses the same key on the keyboard, which has key code 65 (equal to upper case ASCII, as you see).

keyCode

charCode

Therefore, onkeydown/up keyCode always holds the key code. onkeypress you can find the actual character the user typed by evt.charCode || evt.keyCode.

Punctuation keys

I decided not to test the punctuation keys. I suspect that these keys are dependant not only on browser and operating system, but also on keyboard configuration and the official system language. I work on a Dutch Windows, but with a US 101 keyboard configuration, and I wouldn't be surprised if that matters a lot in punctuation keys experiments.

For instance, shift + , causes a < character to appear in my applications, but the ASCII value returned by my test script belongs to the ?. When I discovered that I decided not to risk my sanity by performing further punctuation character experiments.

Special keys

The special keys encompass all those keys that don't cause a character to appear, but execute a certain function. For instance, shift, escape, pageDown, and enter are all special keys.

Some general caveats:

• Generally, Mac is less reliable than Windows, and some keys cannot be detected.
• Explorer doesn't fire the keypress event for delete, end, enter, escape, function keys, home, insert, pageUp/Down and tab.
• Onkeypress, Safari gives weird keyCode values in the 63200 range for delete, end, function keys, home and pageUp.Down. The onkeydown and -up values are normal.
• Alt, Cmd, Ctrl and Shift cannot be detected on Mac, except in Opera. However, you can always use the altKey, ctrlKey, and shiftKey properties.

If you need to detect these keys, do yourself a favour and search for their keyCode onkeydown/up, and ignore both onkeypress and charCode.

Test