This section is informative
The relationship of each key to the complete keyboard has three separate aspects, each of which vary among different models and configurations of keyboards, particularly for locale-specific reasons:
- Visual markings: the labels (or legends) that mark each key
- Mechanical layout: the dimensions, size, and placement of the physical keys on the keyboard
- Functional mapping: the abstract key-value association of each key.
This specification only defines the functional mapping, in terms of key values, but briefly describes key legends and keyboard layout for background.
This section is informative
The visual markings normally consist of one or more characters which a keystroke on that key will produce (such as 'F', '8', or 'ш'), or names or symbols which indicate that key's function (such as an upward-pointing arrow ⇧ indicating 'Shift', or the string 'Enter'). Keys are often referred to by this marking (e.g. “Press the 'Shift' and 'F' keys.”). However, the visual appearance of the key has no bearing on its digital representation, and in many configurations may be completely inaccurate; even the control and function keys, such as 'Enter', may be mapped to different functionality, or even mapped as character keys.
For historical reasons, the character keys are typically marked with the capital-letter equivalents of the character value they produce, e.g. the 'F' key (the key marked with the glyph 'F'), will produce the character value 'f' when pressing without an active modifier key ('Shift') or modifier state ('CapsLock').
Note that the key legends for function keys do not normally produce any characters, although the symbol may have a Unicode equivalent; for example, the 'Shift' key may bear the symbol ⇧, which has the Unicode code point '21E7', but pressing the 'Shift' key will not produce this character value, and there is no Unicode code point for 'Shift'.
This section is informative
As with the key labels, the physical layout of the keys on the keyboard does not not affect the digital key value for any given key. It is outside the scope of this specification to provide key values based on keyboard layout, particularly since there are so many possible layouts for a keyboard, and since users can change the mapping of keys in their operating system, e.g. by selecting a Dvorak key mapping.
To illustrate the concept of keyboard layout mappings and its relation with keyboard events and key values, on the same keyboard (a PC/AT US keyboard), pressing the key labeled Q (with no modifier key activated) will produce different key values based on the mapping. With a typical US QWERTY keyboard layout mapping, it will produce the character 'q' (U+0071, Latin Small Letter Q). If the keyboard layout mapping is switched to a French mapping, pressing the same key will produce the character 'a' (U+0041, Latin Capital Letter A). If the keyboard layout mapping is switched to a Serbian (Cyrillic) mapping, pressing the same key will produce the character 'љ' (U+0459, Cyrillic Small Letter LJE).
However, the physical layout of the keys may be of interest to content authors developing games or other applications in which the location of the keys has an ergonomic relationship as the desired user interface controls, with little or no attention paid to the representational value of the key itself. For example, many games may use the keys 'A', 'S', 'D', and 'W' for 'left', 'down', 'right', and 'up' respectively. Content authors should provide a means for the user to assign such controller keys to a custom setting appropriate to their keyboard configurations. Implementations may provide a means for the user to more comprehensively map the keyboard to their customized keyboard layout, but this is beyond the scope of this specification.
Note: Key values should not be confused with scan codes, which are the low-level hexadecimal signals produced for each key by the keyboard driver software, and which are mapped at the operating system to a VK ("virtual key"), which in turn may be mapped to the user-defined key configuration. Key values are a high-level abstraction of that final mapping.
In the case where a content author wishes to rely on the mechanical layout of a desktop or laptop keyboard, this specification suggests the keyboard configuration specified in ISO/IEC 9995, parts 2 and 3 [ISO-9995-2/3], which defines a common layout for primary, secondary, and auxiliary key mappings on a typical alphanumeric keyboard, as a common layout appropriate to some international uses.
Note: This keyboard layout is still, in essence, a QWERTY keyboard, and will not match the keyboards or configurations of many users. Content authors cannot rely upon any particular configuration, and should create content in an internationalized and localizable manner.
In the case where a content author wishes to rely on the mechanical layout of a mobile keypad, this specification suggests the keyboard configuration specified in ISO/IEC 9995-8:2006 [ISO-9995-8], which defines a numeric keypad layout and secondary assignment of Unicode characters in the range \u0061..\u007A to the number keys 2 through 9, as a common layout appropriate to some international uses.
Note: This keypad layout, and in particular the distribution of letters is for English devices, and will not match the keypads or configurations of many users. Content authors cannot rely upon any particular configuration, and should create content in an internationalized and localizable manner.
Virtual keyboards are software-based sets of keys, in a variety of different arrangements, commonly found on touch-screen devices; they are often modal, with the ability to switch between different dynamic sets of keys, such as alphabetic, numeric, or symbolic keys. Because of the lack of physical constraints, these keyboards may present the widest range of characters, including emoticons and other symbols, and may have keys not represented by Unicode [Unicode] or by the key values set defined in this specification. Wherever possible, however, virtual keyboards should produce the normal range of keyboard events and values, for ease of authoring and compatibility with existing content.
Chording keyboards, also know as chorded keysets or chord keyboards, are key input devices which produce values by pressing several keys in combination or sequence, normally to simulate a full range of characters or commands on a reduced set of keys, often for single-handed use. A chording keyboard may have additional mode keys to switch between key values, and the number and type of keys pressed to produce a key value will vary, but the final key values produced by such keyboards should match the range of key values described in this specification.
For these and other alternative modal keyboards, the key values 'Alphanumeric', 'CapsLock', 'NumLock', and 'SymbolLock' are recommended for the keys which switch between different modes.
A key value is a DOMString that can be used to indicate any given key on a keyboard, regardless of position or state, by the value it produces. These key values may be used as return values for keyboard events generated by the implementation, or as input values by the content author to specify desired input (such as for keyboard shortcuts). This specification defines a set of common key values (called the Key Values Set), and rules for production of new key values.
Issue: Add mention of textInput and it's relationship to key values, per Ishida
Key values can be used to detect the value of a key which has been pressed, using the KeyboardEvent.key or KeyboardEvent.char attributes. Content authors can retrieve the character value of upper- or lower-case letters, number, symbols, or other character-producing keys, and also the key value of control keys, modifier keys, function keys, or other keys that do not generate characters; these values can be used for monitoring particular input strings, for detecting and acting on modifier key input in combination with other inputs (such as a mouse), for creating virtual keyboards, or for any number of other purposes.
Key values can also be used by content authors in string comparisons, as values for markup attributes (such as the HTML accesskey) in conforming host languages, or for other related purposes. A conforming host language should allow content authors to use either of the two equivalent string values for a key value: the character value, or the key value.
Issue: mention that content author should use case-insensitive matching to capture both "t" and "T" for hotkeys, etc.?
Note: While implementations are recommended to use the most relevant value for a key independently of the platform or keyboard layout mappings, content authors should not make assumption on the ability of keyboard devices to generate them. When using keyboard events and key values for shortcut-key combinations, content authors should consider using numbers and function keys (F4, F5, and so on) instead of letters
([DWW95]) given that most keyboard layouts will provide keys for those.
It is important to note that a key value does not indicate a specific key on the physical keyboard, nor does it reflect the character printed on the key; a key value indicates the current value of the event with consideration to the current state of all active keys and key input modes (including shift modes and dead keys), as reflected in the operating-system mapping of the keyboard and reported to the implementation. In other words, the key value for the key marked 'O' on a QWERTY keyboard has the key value 'o' in an unshifted state, 'O' in a shifted state, 'ö' in an unshifted state during a dead-key operation to add an umlaut diacritic, and 'Ö' in a shifted state during a dead-key operation to add an umlaut diacritic. Because a user may map their keyboard to an arbitrary custom configuration, the content author should not assume that a relationship exists between the shifted and unshifted states of a key and the majuscule form (uppercase or capital letters) and minuscule form (lowercase or small letters) of a character representation, but should instead use the value of the KeyboardEvent.key or KeyboardEvent.char attributes. The keyboard depicted in Figure 3 illustrates one possible set of key mappings on one possible keyboard layout; many others exist, both standard and idiosyncratic.
It is also important to note that there is not a one-to-one relationship between key event states and key values. A particular key value may be associated with multiple keys; for example, many standard keyboards contain more than one key with the 'Shift' key value (normally distinguished by the KeyboardEvent.location values DOM_KEY_LOCATION_LEFT and DOM_KEY_LOCATION_RIGHT) or '8' key value (normally distinguished by the KeyboardEvent.location values DOM_KEY_LOCATION_STANDARD and DOM_KEY_LOCATION_NUMPAD), and user-configured custom keyboard layouts may duplicate any key value in multiple key-state scenarios (note that KeyboardEvent.location is intended for standard keyboard layouts, and cannot always indicate a meaningful distinction).
Similarly, a given key event state may have different key values. For most keys which represent characters, such as the letter 'm' or the question mark ('?'), the KeyboardEvent.key and KeyboardEvent.char attributes will be the same. However, for printing control characters, such as the backspace/back key, the character value is distinct from the key value, with different values for the KeyboardEvent.key and KeyboardEvent.char attributes; see the Key Values Set for more details. Certain keys in some states, called modifier keys or control keys, have only a key value and no character value, such as the volume mute key, which has the KeyboardEvent.key attribute value 'VolumeMute' and the KeyboardEvent.char attribute value null.
Finally, the meaning of any given character representation is context-dependent and complex. For example, in some contexts, the asterisk (star) glyph ('*') represents a footnote or emphasis (when bracketing a passage of text); however, in some documents or executable programs it is equivalent to the mathematical multiplication operation, while in other documents or executable programs, that function is reserved for the multiplication symbol ('×', Unicode value U+00D7) or the Latin small letter 'x' (due to the lack of a multiplication key on many keyboard and the superficial resemblance of the glyphs '×' and 'x'). Thus, the semantic meaning or function of character representations is outside the scope of this specification.
The character values described in this specification are Unicode [Unicode] codepoints, and as such, have certain advantages.
The most obvious advantage is that it allows the content author to use the full range of internationalized language functionality available in the implementation, regardless of the limitations of the text input devices on the system. This opens up possibilities for virtual keyboards and Web-application-based input method editors.
Another benefit is that it allows the content author to utilize the Unicode general category properties programmatically.
With legacy keyboard event attributes such as keyCode and charCode, content authors are forced to filter key input using cryptic, platform- and implementation-specific numeric codes, with poor internationalization, such as the following pseudocode:
Example:
if ( ( event.charCode == 45 || event.charCode == 36 ) ||
( event.charCode >= 48 && event.charCode <= 57 ) ||
( event.charCode >= 96 && event.charCode <= 105 ) ) {
// minus sign, dollar sign, and numeric characters from keyboard and numpad
...
}
else if ( ( event.charCode >= 65 && event.charCode <= 90 ) ||
( event.charCode >= 97 && event.charCode <= 122 ) ) {
// alphabetic characters from Latin character set, A-Z, a-z
...
}
else {
...
}
With key values and regular expressions, however, content authors can support selective and intuitive ranges for key-based input, in a cross-platform manner with advanced internationalization support, such as the following pseudocode:
Example:
if ( event.key == "-" ||
event.key.match("\p{Sc}") ||
event.key.match("\p{N}") ) {
// minus sign, any currency symbol, and numeric characters (regardless of key location)
...
}
else if ( event.key.match("\p{L}") ) {
// alphabetic characters from any language, upper and lower case
...
}
else {
...
}
In addition, because Unicode categorizes each assigned code point into a group of code points used by a particular human writing system, even more advanced capabilities are possible. For example, a content author can match characters from a particular human script (e.g. Tibetan) using a regular expression such as \p{Tibetan}, to filter out other characters, or discover if a code point is in a certain code block (range of code points), using a regular expression like \p{InCyrillic}.
To facilitate this, implementations should support Unicode range detection using regular expressions, in a manner such as the Perl Compatible Regular Expressions (PCRE) [PCRE].
Keyboard input uses modifier keys to change the normal behavior of a key. Like other keys, modifier keys generate keydown and keyup events, as shown in the example below. Some modifiers are activated while the key is being pressed down or maintained pressed such as 'Alt', 'Control', 'Shift', 'AltGraph', or 'Meta'. Others modifiers are activated depending on their state such as 'CapsLock', 'NumLock', or 'Scroll'. Change in the state happens when the modifier key is being pressed down. The KeyboardEvent interface provides convenient attributes for some common modifiers keys: KeyboardEvent.ctrlKey, KeyboardEvent.shiftKey, KeyboardEvent.altKey, KeyboardEvent.metaKey. Some operating systems simulate the 'AltGraph' modifier key with the combination of the "Alt and 'Control' modifier keys. Implementations are encouraged to use the 'AltGraph' modifier key.
The following example describes a possible sequence of events associated with the generation of the Unicode character Q (Latin Capital Letter Q, Unicode code point U+0051) on a PC/AT US keyboard using a US mapping:
Issue: Reformat example as table with "Event", "Returned value", and "Keys involved", per Ishida?
The following example describes an alternate sequence of keys to the example above, where the 'Shift' key is released before the 'Q' key. The key value for the key labeled 'Q' will revert to its unshifted value for the keyup event, after the production of the textInput event, thus:
The following example describes a possible sequence of keys that does not generate a Unicode character (using the same configuration):
Example:
keydown: 'Control', ctrlKeykeydown: 'v' (U+0076, Latin Small Letter V key), ctrlKeykeyup: 'v' (U+0076, Latin Small Letter V key), ctrlKeykeyup: 'Control'
In some cases, modifier keys change the key value value for a key event. For example, on some MacOS keyboards, the key labeled 'delete' functions the same as the 'Backspace' key on the Windows OS when unmodified, but when modified by the 'Fn' key, acts as the 'Del' key, and the value of the key value must match the most appropriate function of the key in its current modified state.
Some keyboard input uses dead keys for the input of composed character sequences. Unlike the handwriting sequence, in which users enter the base character first, keyboard input requires to enter a special state when a dead key is pressed and emit the character(s) only when one of a limited number of “legal” base character is entered. (NOTE: the MacOS and Linux operating systems use input methods to process dead keys.)
The dead keys are represented in the key values set using combining diacritical marks. While Unicode combining characters always follow the handwriting sequence, with the combining character trailing the corresponding letter, typical deadkey input may reverse the sequence, with the combining character before the corresponding letter; for example, the word naïve, using the combining diacritic ¨, would be represented sequentially in Unicode as nai¨ve, but may be typed na¨ive. The sequence of keystrokes '\u0302' (Combining Circumflex Accent key) and '\u0065' (key marked with the Latin Small Letter E) will likely produce (on a PC/AT french keyboard using a french mapping and without any modifier activated) the Unicode character ê (Latin Small Letter E With Circumflex), as preferred by the Unicode Normalization Form NFC:
Example:
keydown: \u0302 (Combining Circumflex Accent key)compositionstart: \u0302 (Combining Circumflex Accent key)compositionupdate: \u0302 (Combining Circumflex Accent key)keyup: \u0302 (Combining Circumflex Accent key)keydown: 'ê' (U+00EA, LATIN SMALL LETTER E WITH CIRCUMFLEX)
Note: the key value will not be 'e' (Latin Small Letter E key) under normal circumstances, because the value delivered to the user agent will already be modified by the dead key operation.
Issue: is this correct for the case of composition events?
compositionend: 'ê'textInput: 'ê' ("inputMethod": 'DOM_INPUT_METHOD_IME')keyup: 'e' (U+0065, Latin Small Letter E key)
This process may be aborted when a user types an unsupported base character (that is, a base character for which the which the active diacritical mark is not available) after pressing a dead key:
Example:
keydown: \u0302 (Combining Circumflex Accent key)compositionstart: \u0302 (Combining Circumflex Accent key)compositionupdate: \u0302 (Combining Circumflex Accent key)keyup: \u0302 (Combining Circumflex Accent key)keydown: 'q' (U+0071, The Latin Small Letter Q key)compositionend: ''textInput: 'q' ("inputMethod": 'DOM_INPUT_METHOD_KEYBOARD')keyup: 'q' (U+0071, The Latin Small Letter Q key)
This specification includes a model for input method editors (IMEs), through the CompositionEvent interface and events. However, composition events and keyboard events do not necessarily map as a one-to-one relationship. As an example, receiving a keydown for the 'Accept' key value does not necessarily imply that the text currently selected in the IME is being accepted, but indicates only that a keystroke happened, disconnected from the IME Accept functionality (which would normally result in a compositionend event in most IME systems). Keyboard events cannot be used to determine the current state of the input method editor, which should be obtained through the data attribute of the CompositionEvent interface. Additionally, IME systems and devices vary in their functionality, and in which keys are used for activating that functionality, such that the 'Convert' and 'Accept' keys may be represented by other available keys.
Keyboard events correspond to the events generated by the input device after the keyboard layout mapping but before the processing of the input method editor.
The following example describes a possible sequence of keys to generate the Unicode character 市 (Kanji character, part of CJK Unified Ideographs) using Japanese input methods. This example assumes that the input method editor is activated and in the Japanese-Romaji input mode. The keys 'Convert' and 'Accept' may be replaced by others depending on the input device in use and the configuration of the IME, e.g. it could be respectively U+0020 (Space key) and 'Enter'. Note:'詩' ("poem") and '市' ("city") are homophones, both pronounced “shi”, so the user must use the 'Convert' key to select the proper option.
IME composition may also be canceled as in the following example, with conditions identical to the previous example. The key 'Cancel' may also be replaced by others depending on the input device in use and the configuration of the IME, e.g. it could be "\u001B" (Escape key).
NOTE: Some input method editors (such as on the MacOS operating system) may set an empty string to the composition data attribute before canceling a composition.
Some keys on certain devices are intended to activate input method editor functionality, or to change the mode of an active input method editor. Custom keys for this purpose may be defined for different devices or language modes; the keys defined in this specification for this purpose are: Alphanumeric, CodeInput, FinalMode, HangulMode, HanjaMode, Hiragana, JapaneseHiragana, JapaneseKatakana, JapaneseRomaji, JunjaMode, KanaMode, KanjiMode, Katakana, and RomanCharacters. When one of these keys is pressed, and no IME is currently active, the appropriate IME, shall be activated in the mode indicated by the key (if available); if an IME is already active when the key is pressed, the active IME may change to the indicated mode, or a different IME may be launched, or the key may be ignored, on a device- and application-specific basis.
This specification also defines other keys which are intended for operation specifically with input method editors: Accept, AllCandidates, Cancel, Convert, Compose, FullWidth, HalfWidth, NextCandidate, Nonconvert, and PreviousCandidate. The functions of these keys are not defined in this specification; refer to other resources for details on input method editor functionality.
Note that keys with input method editor functions are note restricted to that purpose, and may have other device- or implementation-specific purposes, as well.
Canceling the default action of a keydown event must not affect its respective keyup event, but it must prevent the respective textInput event from being generated. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a PC/AT US keyboard using a US mapping:
If the key is a modifier key, the keystroke must still be taken into account for the modifiers states. The following example describes a possible sequence of keys to generate the Unicode character Q (Latin Capital Letter Q) on a PC/AT US keyboard using a US mapping:
Issue: does this make sense? shouldn't the shift modifier attribute be canceled? needs testing...
If the key is part of a sequence of several keystrokes, whether it is a dead key or it is contributing to an Input Method Editor sequence, the keystroke shall be ignored (not taken into account) only if the default action is canceled on the keydown event. Canceling a dead key on a keyup event has no effect on textInput events. The following example uses the keystrokes U+0302 (Combining Circumflex Accent key) and the key marked 'e' (U+0065, Latin Small Letter E key) (on a PC/AT french keyboard using a french mapping and without any modifier activated):
LATIN SMALL LETTER E WITH ACUTE' (U+00E9)
Note: This section is normative.
The list of key values contained in this specification is not exhaustive, and input devices may have to define their own key values. Consider the current function of the key (i.e., with modifiers), taking into consideration the keyboard layout mapping in use, to determine if the key is represented by the set of defined key values, if a corresponding Unicode character exists from which a key value may be derived, or if a new key value must be defined. The following algorithm determines the key value and character value to use:
- If the primary current function of the key is to generate a character, then:
- If there exists an appropriate character in the key values set, then:
- the
KeyboardEvent.key attribute must be a string consisting of the key value of that character; and
- the
KeyboardEvent.char attribute must be a string consisting of the char value of that character.
- If there is no appropriate key value in the key values set, and there exists an appropriate Unicode code point, then:
- the
KeyboardEvent.key attribute must be a string consisting of the char value of that character; and
- the
KeyboardEvent.char attribute must be a string consisting of the char value of that character.
- If the primary current function of the key is to serve as a function key, then:
- If there exists an appropriate key value in the key values set, then:
- the
KeyboardEvent.key attribute must be a string consisting of the key value of that character; and
- the
KeyboardEvent.char attribute must be null.
- If there is no appropriate key value in the key values set, then a key value must be devised. The key value should be as human friendly as possible and must not contain whitespace characters. The value must be composed only of characters in the ranges \u0030..\u0039, \u0041..\u005A, or \u0061..\u007A, and must begin with a character in the range \u0041..\u005A.
To Do: Update the algorithm example to match the change in the algorithm.
Examples:
- On a PC/AT US keyboard with a right-handed single-hand Dvorak keyboard mapping, the key labeled
'Q' maps to the key values '5' (unmodified) and '%' (shifted). The primary function of this key is to generate the character '5' (U+0035). Since this character is a character (in Unicode general category Nd), the KeyboardEvent.key and KeyboardEvent.char attribute values for the unmodified key will be '5'.
- On a French PC keyboard with a standard French mapping, the primary function of the
'^' key is as a dead key for the circumflex diacritical mark. This corresponds to the combining Unicode character U+0302. Since this character is in general category Mn, the key value shall be U+0302.
- On a Korean PC keyboard with a standard Korean mapping, the primary function of the
'Ha/En' key is to switch between Hangul and English input. The predefined key value list has an appropriate entry for this key, 'HangulMode', so this shall be the key value.
- On some models of mobile devices, the primary function of the key with a picture of a calendar on it is to launch the calendaring program. Since there is no Unicode character that corresponds to this function, and there is no appropriate entry in the predefined key value list, a new value may be devised, such as
'Calendar'.
This section defines a list of key values which implementations must support, at a minimum, in addition to support for the full range of Unicode [Unicode] codepoints. Implementations may support additional key values, in a manner conforming to the guidelines for selecting and defining key values. Each key value defines one or both of the following: a character value and a key value. The KeyboardEvent.key attribute of an event must always contain one of these control key or character values (even if the value is 'Unidentified'), and the KeyboardEvent.char attribute must have a value if the key represents a printable character. If the key represents one of the set of printable control characters which has a Unicode character entry, such as the tab key, the KeyboardEvent.key attribute must have the key value (e.g. 'Tab'), while the KeyboardEvent.char attribute must have the Unicode character value equivalent (e.g. \u0009). This affords content authors the opportunity to deal with the key as a control key or as direct input into the text stream.
The key values defined in this specification are based on the sets of keycodes from the java.awt.event.KeyEvent interface of the Java Platform, Standard Edition 6 API Specification [KeyEvent for Java], and the System.Windows.Forms.Keys key enumeration of the Microsoft .NET Framework 4.0 Class Library [Keys enumeration for .Net]. The character values defined in this specification are derived from the Unicode standard [Unicode].
Note: The key names 'NumPad0', 'NumPad1', 'NumPad2', 'NumPad3', 'NumPad4', 'NumPad5', 'NumPad6', 'NumPad7', 'NumPad8', and 'NumPad9', found in some keyboard enumeration sets, are not distinguished from other numerical key values in this set; a content author may use the KeyboardEvent.location attribute to discover if a key originated from the numeric keypad.
Future versions of this specification may include key values not included here, which have become common since the publication of this specification.
In the following list, character values for printing control characters are described as a character escape, for convenience, using the JavaScript notation for escapes.
Note: There are special internationalization considerations for ECMAScript escaped characters. CharMod conformance [CharMod] expects the use of code points rather than surrogate pairs in escapes; ECMAScript escaped characters use surrogate pairs for characters outside the Basic Multilingual Plane ("\uD84E\uDDC2" for 𣧂, a Chinese character meaning “untidy”), rather than C-style fixed-length characters ("\U000239c2" for 𣧂) or delimited escapes such as Numeric Character References ("𣧂"). Characters escaped in this manner:
- are based on UTF-16 encoding, in that it uses surrogate pairs for values outside the Basic Multilingual Plane
- are expressed using surrogate pairs, which makes it difficult for a human to look up the value, and may require unnecessary overhead for machine processing; this can also cause problems with software written in the incorrect belief that Unicode is a 16-bit character set
- are problematic for characters on supplementary planes (emoji, or Chinese characters on plane 2), some of which may be expected to be input using a keyboard
- may not be suitable for Java or C, which use different escaping mechanisms (could be solved with a normalizing method)
Legend for the following list:
- Key values are denoted with a
blue background, and are the first term in a set
- Character values, where present, are denoted with a
green background, and follow the key value.
'Accept'- The Accept (Commit, OK) key.
'Add'- The Add key.
'Again'- The Again key.
'AllCandidates'- The All Candidates key.
'Alphanumeric'- The Alphanumeric key.
'Alt'- The Alt (Menu) key.
'AltGraph'- The Alt-Graph key.
'Apps'- The Application key.
'Attn'- The ATTN key.
'BrowserBack'- The Browser Back key.
'BrowserFavorites'- The Browser Favorites key.
'BrowserForward'- The Browser Forward key.
'BrowserHome'- The Browser Home key.
'BrowserRefresh'- The Browser Refresh key.
'BrowserSearch'- The Browser Search key.
'BrowserStop'- The Browser Stop key.
'Camera'- The Camera key.
'CapsLock'- The Caps Lock (Capital) key.
'Clear'- The Clear key.
'CodeInput'- The Code Input key.
'Compose'- The Compose key.
'Control'- The Control (Ctrl) key.
'Crsel'- The Crsel key.
'Convert'- The Convert key.
'Copy'- The Copy key.
'Cut'- The Cut key.
'Decimal'- The Decimal key.
'Divide'- The Divide key.
'Down'- The Down Arrow key.
'DownLeft'- The diagonal Down-Left Arrow key.
'DownRight'- The diagonal Down-Right Arrow key.
'Eject'- The Eject key.
'End'- The End key.
'Enter'- The Enter key.
Note: This key value must also be used for the
Return (Macintosh numpad) key.
'EraseEof'- The Erase EOF key.
'Execute'- The Execute key.
'Exsel'- The Exsel key.
'Fn'- The Function switch key.
'F1'- The F1 key.
'F2'- The F2 key.
'F3'- The F3 key.
'F4'- The F4 key.
'F5'- The F5 key.
'F6'- The F6 key.
'F7'- The F7 key.
'F8'- The F8 key.
'F9'- The F9 key.
'F10'- The F10 key.
'F11'- The F11 key.
'F12'- The F12 key.
'F13'- The F13 key.
'F14'- The F14 key.
'F15'- The F15 key.
'F16'- The F16 key.
'F17'- The F17 key.
'F18'- The F18 key.
'F19'- The F19 key.
'F20'- The F20 key.
'F21'- The F21 key.
'F22'- The F22 key.
'F23'- The F23 key.
'F24'- The F24 key.
'FinalMode'- The Final Mode (Final) key used on some asian keyboards.
'Find'- The Find key.
'FullWidth'- The Full-Width Characters key.
'HalfWidth'- The Half-Width Characters key.
'HangulMode'- The Hangul (Korean characters) Mode key.
'HanjaMode'- The Hanja (Korean characters) Mode key.
'Help'- The Help key.
'Hiragana'- The Hiragana (Japanese Kana characters) key.
'Home'- The Home key.
'Insert'- The Insert (Ins) key.
'JapaneseHiragana'- The Japanese-Hiragana key.
'JapaneseKatakana'- The Japanese-Katakana key.
'JapaneseRomaji'- The Japanese-Romaji key.
'JunjaMode'- The Junja Mode key.
'KanaMode'- The Kana Mode (Kana Lock) key.
'KanjiMode'- The Kanji (Japanese name for ideographic characters of Chinese origin) Mode key.
'Katakana'- The Katakana (Japanese Kana characters) key.
'LaunchApplication1'- The Start Application One key.
'LaunchApplication2'- The Start Application Two key.
'LaunchMail'- The Start Mail key.
'Left'- The Left Arrow key.
- The Menu key.
'Meta'- The Meta key.
Note: This key value shall be also used for the Apple
Command key.
'MediaNextTrack'- The Media Next Track key.
'MediaPlayPause'- The Media Play Pause key.
'MediaPreviousTrack'- The Media Previous Track key.
'MediaStop'- The Media Stop key.
'ModeChange'- The Mode Change key.
'NextCandidate'- The Next Candidate function key.
'Nonconvert'- The Nonconvert (Don't Convert) key.
'NumLock'- The Number Lock key.
'PageDown'- The Page Down (Next) key.
'PageUp'- The Page Up key.
'Paste'- The Paste key.
'Pause'- The Pause key.
'Play'- The Play key.
'Power'- The Power key.
Note: Some devices may not expose this key to the operating environment.
'PreviousCandidate'- The Previous Candidate function key.
'PrintScreen'- The Print Screen (PrintScrn, SnapShot) key.
'Process'- The Process key.
'Props'- The Props key.
'Right'- The Right Arrow key.
'RomanCharacters'- The Roman Characters function key.
'Scroll'- The Scroll Lock key.
'Select'- The Select key.
'SelectMedia'- The Select Media key.
'Separator'- The Separator key.
'Shift'- The Shift key.
'Soft1'- The Soft1 key.
'Soft2'- The Soft2 key.
'Soft3'- The Soft3 key.
'Soft4'- The Soft4 key.
'Stop'- The Stop key.
'Subtract'- The Subtract key.
'SymbolLock'- The Symbol Lock key.
'Up'- The Up Arrow key.
'UpLeft'- The diagonal Up-Left Arrow key.
'UpRight'- The diagonal Up-Right Arrow key.
'Undo'- The Undo key.
'VolumeDown'- The Volume Down key.
'VolumeMute'- The Volume Mute key.
'VolumeUp'- The Volume Up key.
'Win'- The Windows Logo key.
'Zoom'- The Zoom key.
'Backspace'\u0008- The Backspace (Back) key.
Note: This key value shall be also used for the key labeled
'delete' MacOS keyboards when not modified by the 'Fn' key.
'Tab'\u0009- The Horizontal Tabulation (Tab) key.
'Cancel'\u0018- The Cancel key.
'Esc'\u001B- The Escape (Esc) key.
'Spacebar'\u0020- The Space (Spacebar) key:
.
'Del'\u007F- The Delete (Del) Key.
Note: This key value shall be also used for the key labeled
'delete' MacOS keyboards when modified by the 'Fn' key.
'DeadGrave'\u0300- The Combining Grave Accent (Greek Varia, Dead Grave) key.
'DeadEacute'\u0301- The Combining Acute Accent (Stress Mark, Greek Oxia, Tonos, Dead Eacute) key.
'DeadCircumflex'\u0302- The Combining Circumflex Accent (Hat, Dead Circumflex) key.
'DeadTilde'\u0303- The Combining Tilde (Dead Tilde) key.
'DeadMacron'\u0304- The Combining Macron (Long, Dead Macron) key.
'DeadBreve'\u0306- The Combining Breve (Short, Dead Breve) key.
'DeadAboveDot'\u0307- The Combining Dot Above (Derivative, Dead Above Dot) key.
'DeadUmlaut'\u0308- The Combining Diaeresis (Double Dot Abode, Umlaut, Greek Dialytika, Double Derivative, Dead Diaeresis) key.
'DeadAboveRing'\u030A- The Combining Ring Above (Dead Above Ring) key.
'DeadDoubleacute'\u030B- The Combining Double Acute Accent (Dead Doubleacute) key.
'DeadCaron'\u030C- The Combining Caron (Hacek, V Above, Dead Caron) key.
'DeadCedilla'\u0327- The Combining Cedilla (Dead Cedilla) key.
'DeadOgonek'\u0328- The Combining Ogonek (Nasal Hook, Dead Ogonek) key.
'DeadIota'\u0345- The Combining Greek Ypogegrammeni (Greek Non-Spacing Iota Below, Iota Subscript, Dead Iota) key.
'DeadVoicedSound'\u3099- The Combining Katakana-Hiragana Voiced Sound Mark (Dead Voiced Sound) key.
'DeadSemivoicedSound'\u309A- The Combining Katakana-Hiragana Semi-Voiced Sound Mark (Dead Semivoiced Sound) key.
'Unidentified'- This key value is used when an implementations is unable to identify another key value, due to either hardware, platform, or software constraints. Warning! Conforming implementation must only use this key value when there is no way for the implementation to detect the key value, and does not indicate a conforming implementation by itself.
Browser support for keyboards has traditionally relied on three ad-hoc attributes, keyCode, charCode, and which.
All three of these attributes return a numerical code that represents some aspect of the key pressed: keyCode is an index of the key itself; charCode is the ASCII value of the character keys; which is the character value where available and otherwise the key index. The values for these attributes, and the availability of the attribute, is inconsistent across platforms, keyboard languages and layouts, user agents, versions, and even event types. A significant amount of legacy content, including script libraries, relies upon detecting the user agent and acting accordingly, and any changes to keyCode, charCode, or which risk breaking as much content as they fix or enable. Additionally, these attributes are not suitable for international usage, or accessibility concerns.
Therefore, this specification does not normatively define the values for the keyCode, charCode, or which attributes, relying instead only on the more robust key values, which can be used safely and consistently in any user agent which conforms to this specification.
However, for the purpose of documenting the current state of these attributes and their relation to equivalent key values, this specification refers to the Legacy Keyboard Event Properties [KeyProps] WG Note, which contains an informative reference table that documents some common values for the keyCode and charCode properties in different implementations.
Additionally, in order to provide raw access to any available environment-specific keys, absent the effect of modifier keys, the KeyboardEvent interface does define the legacy KeyboardEvent.keyCode attribute, but the value of the attribute may vary between implementations and even between the same implementation on different operating systems. Normally, for modified values, the KeyboardEvent.key attribute should be used instead of the KeyboardEvent.keyCode attribute.
This specification does not define the charCode or which attributes on the KeyboardEvent interface, though they may be present in user agents for compatibility with legacy content. The KeyboardEvent.char attribute should be used instead of the charCode attribute.