Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://developer.cdn.mozilla.net/en-US/docs/Web/API/KeyboardEvent/keyCode below:

KeyboardEvent: keyCode property - Web APIs

Deprecated: This feature is no longer recommended. Though some browsers might still support it, it may have already been removed from the relevant web standards, may be in the process of being dropped, or may only be kept for compatibility purposes. Avoid using it, and update existing code if possible; see the compatibility table at the bottom of this page to guide your decision. Be aware that this feature may cease to work at any time.

The deprecated KeyboardEvent.keyCode read-only property represents a system and implementation dependent numerical code identifying the unmodified value of the pressed key.

This is usually the decimal ASCII (RFC 20) or Windows 1252 code corresponding to the key. If the key can't be identified, this value is 0.

You should avoid using this if possible; it's been deprecated for some time. Instead, you should use KeyboardEvent.code (for the physical key pressed) or KeyboardEvent.key (for the character the key maps to). Check compatibility for either property if you target very old browsers.

Note: Web developers shouldn't use the keyCode attribute for printable characters when handling keydown and keyup events. As described above, the keyCode attribute is not useful for printable characters, especially those input with the Shift or Alt key pressed.

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.

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

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:

Warning: The purpose of these new additional rules is for making users whose keyboard layouts map unicode characters to punctuation keys in a US keyboard layout can use web applications which support Firefox only with ASCII-capable keyboard layouts or just with a US keyboard layout. Otherwise, the newly mapped keyCode values may be conflict with other keys. For example, if the active keyboard layout is Russian, the keyCode value of both the "Period" key and "Slash" key are 190 (KeyEvent.DOM_VK_PERIOD). If you need to distinguish those keys but you don't want to support all keyboard layouts in the world by yourself, you should probably use KeyboardEvent.code.

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, pressing the AltGraph key raises both the "ControlLeft" and the "AltRight" key events.

[2] When the Japanese keyboard layout is active, pressing the CapsLock key without pressing Shift raises 0xF0 (240). The key works as the Alphanumeric key whose label is "英数".

[3] When the Japanese keyboard layout is active, pressing the "CapsLock" key without pressing Shift raises 0x00 (0). The key works as the "Alphanumeric" key whose label is "英数".

[1] A keypress event is fired and its keyCode and charCode are 0x10 (16) but the text isn't actually entered into the editor.

[2] On Mac, the Help key is mapped to the Insert key of PC keyboards. These keyCode values are the same as the Insert key's keyCode values.

[3] Tested on Fedora 20.

[4] Only a keyup event is fired.

[5] PC's PrintScreen, ScrollLock and Pause are mapped to Mac's F13, F14 and F15, respectively. Chrome and Safari map them to the same keyCode values as Mac's keys.

[6] Pause key with Control generates 0x03 (3).

[1] Tested on Fedora 20.

[2] On PCs, PrintScreen, ScrollLock and Pause are mapped to the Mac's F13, F14 and F15, respectively. Firefox sets for them the same keyCode values as the 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] The keyCode value of a keyUp event is 0x83 (131).

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

[7] Only the keydown event is fired.

[8] No DOM key events are fired on Firefox.

[1] "NumLock" key works as "Clear" key on Mac.

Note: Recent Mac doesn't have a NumLock key, and therefore state. That's why the unlocked state is not 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.

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

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

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

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.

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4