KeyboardEvent.keyCode

Die schreibgeschütze Eigenschaft KeyboardEvent.keyCode  stellt den den unveränderten,  System- und Implementationsabhängigen numerischen Bezeichner der gedrückten Taste dar. Normalerweise ist das der zugehörige  ASCII RFC 20) oder Windows 1252 Code der Taste. Bei einer unerkannten Taste ist das der Wert 0.

Der Wert des keypress Ereignis unterscheided sich von Browser zu Browser. IE und Google Chrome setzen den KeyboardEvent.charCode  Wert. Gecko setzt 0 wenn die gedrückte Taste ein druckbares Zeichen darstellt, andernfalls ist es der selbe Wert wie beim keydown und keyup Ereignis.

Von der Verwendung dieser Eigenschaft sollte nach Möglichkeit abgesehen werden, da siebereits seit einiger Zeit veraltet ist. Statdessen sollte {domxref("KeyboardEvent.code")}} verwendet werden, so es implementiert ist. Leider gibt es noch immer einige Browser ohne Unterstützung dafür. Google und Safari implementieren KeyboardEvent.keyIdentifier, der bisher in der Entwurfs-Spezifikation enthalten ist,  nicht jedoch in der finalen Version.

window.addEventListener("keydown", function (event) {
  if (event.defaultPrevented) {
    return; // Should do nothing if the default action has been cancelled
  }

  var handled = false;
  if (event.key !== undefined) {
    // Handle the event with KeyboardEvent.key and set handled true.
  } else if (event.keyIdentifier !== undefined) {
    // Handle the event with KeyboardEvent.keyIdentifier and set handled true.
  } else if (event.keyCode !== undefined) {
    // Handle the event with KeyboardEvent.keyCode and set handled true.
  }

  if (handled) {
    // Suppress "double action" if event handled
    event.preventDefault();
  }
}, true);

The value of key events which are caused by pressing or releasing printable keys in standard position is not compatible between browsers.

IE just exposes the native virtual keycode value as KeyboardEvent.keyCode.

Google Chrome, Chromium and Safari must decide the value from the input character. If the inputting character can be inputted with the US keyboard layout, they use the keyCode value on the US keyboard layout.

Starting in Firefox 15 (Firefox 15.0 / Thunderbird 15.0 / SeaMonkey 2.12), Gecko gets keyCode values from ASCII characters inputtable by the key — even with shift modifiers or an ASCII capable keyboard layout. See the following rules for details:

1. If the system is Windows and the native keycode of the pressed key indicates that the key is a-z or 0-9, use a keycode for it.
2. If the system is Mac and the native keycode of the pressed key indicates that the key is 0-9, use a keycode for it.
3. If the pressed key inputs an ASCII alphabetic or numeric character with no modifier key, use a keycode for it.
4. If the pressed key inputs an ASCII alphabetic or numeric character with a Shift key modifier, use a keycode for it.
5. If the pressed key inputs a different ASCII character with no modifier key, use a keycode for it.
6. If the pressed key inputs a different ASCII character with a Shift key modifier, use a keycode for it.
7. Otherwise, i.e., pressed key inputs a unicode character:
   1. If the keyboard layout is ASCII-capable (i.e., can input ASCII alphabets), use 0 or compute with the following additional rules.
   2. Otherwise, i.e., the keyboard layout isn't ASCII capable, use the ASCII capable keyboard layout installed on the environment with the highest priority:
      1. If the pressed key on the alternative keyboard layout inputs an ASCII alphabetic or numeric character, use a keycode for it.
      2. Otherwise, use 0 or compute with the following additional rules.

Starting in Firefox 60 (Firefox 60.0 / Thunderbird 60.0 / SeaMonkey 2.57), Gecko sets keyCode values of punctuation keys as far as possible (when points 7.1 or 7.2 in the above list are reached) with the following rules:

1. If running macOS or Linux:
   1. If the active keyboard layout is not ASCII-capable and an alternative ASCII-capable keyboard layout is available.
      1. If the alternative ASCII-capable keyboard layout produces an ASCII character via just the unmodified key, use a keyCode for the character.
      2. If the alternative ASCII-capable keyboard layout produces an ASCII character with a Shift key modifier, use a keyCode for the shifted character.
      3. Otherwise, use a keyCode for an ASCII character produced by the key when the US keyboard layout is active.
   2. Otherwise, use a keyCode for an ASCII character produced by the key when the US keyboard layout is active.
2. If running on Windows:
   1. Use a keyCode value for an ASCII character produced by a key which is mapped to the same virtual keycode of Windows when the US keyboard layout is active.

*1 The value is input from JIS keyboard. When you use ANSI keyboard, the keyCode value and inputted character are what you select from the US keyboard layout.

*2 The key is a dead key. The value of keyup event is 0xBA (186).

*3 The key is a dead key. The value of keyup event is 0x10 (16).

*4 No key events are fired.

*5 The key isn't available with Greek keyboard layout (does not input any character). The value of keyup event is 0x00 (0).

*1 On Windows, "AltGraph" key causes "ControlLeft" key event and "AltRight" key event.

*2 When Japanese keyboard layout is active, "CapsLock" key without Shift causes 0xF0 (240). The key works as "Alphanumeric" key whose label is "英数".

*3 When Japanese keyboard layout is active, "CapsLock" key without Shift causes 0x00 (0). The key works as "Alphanumeric" key whose label is "英数".

*1 keypress event is fired whose keyCode and charCode are 0x10 (16) but text isn't inputted into editor.

*2 On Mac, "Help" key is mapped to "Insert" key of PC keyboard. These keyCode values are the same as the "Insert" key's keyCode value.

*3 Tested on Fedora 20.

*4 Only keyup event is fired.

*5 PC's "PrintScreen", "ScrollLock" and "Pause" are mapped to Mac's "F13", "F14" and "F15". Chrome and Safari map same keyCode values with Mac's keys.

*6 "Pause" key with Control causes 0x03 (3).

*1 Tested on Fedora 20.

*2 PC's "PrintScreen", "ScrollLock" and "Pause" are mapped to Mac's "F13", "F14" and "F15". Firefox maps same keyCode values with PC's keys.

*3 Tested on Fedora 20. The keys don't cause GDK_Fxx keysyms. If the keys cause proper keysyms, these values must be same as IE.

*4 Tested on Fedora 20. The keys don't cause DOM key events on Chromium.

*5 keyUp event's keyCode value is 0x83 (131).

*6 Tested on Fedora 20. The keys don't cause DOM key events on Firefox.

*7 Only keydown event is fired.

*8 No DOM key events are fired on Firefox.

*1 "NumLock" key works as "Clear" key on Mac.

* Recent Mac doesn't have "NumLock" key and state. Therefore, unlocked state isn't available.

Gecko defines a lot of keyCode values in KeyboardEvent for making the mapping table explicitly. These values are useful for add-on developers of Firefox, but not so useful in public web pages.

On Windows, some values of virtual keycode are defined (reserved) for OEM specific key. They are available for special keys on non-standard keyboard. In other words, some values are used for different meaning by two or more vendors (or hardware).

Starting Gecko 21 (and older than 15), OEM specific key values are available on the keyCode attribute only on Windows. So they are not useful for usual web applications. They are useful only for intranet applications or in similar situations.

See "Manufacturer-specific Virtual-Key Codes (Windows CE 5.0)" in MSDN for the detail.