1.1 Overview

DOM Events is designed with two main goals. The first goal is the design of an event system which allows registration of event listeners and describes event flow through a tree structure. Additionally, the specification will provide standard modules of events for user interface control and document mutation notifications, including defined contextual information for each of these event modules.

The second goal of DOM Events is to provide a common subset of the current event systems used in existing browsers. This is intended to foster interoperability of existing scripts and content. It is not expected that this goal will be met with full backwards compatibility. However, the specification attempts to achieve this when possible.

1.2 Conformance

This section is normative.

Within this specification, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119].

This specification is to be understood in the context of the DOM Level 3 Core specification [DOM3 Core] and the general considerations for DOM implementations apply. For example, handling of namespace URIs is discussed in XML Namespaces. For additional information about conformance, please see the DOM Level 3 Core specification [DOM3 Core]. A user agent is not required to conform to the entirety of another specification in order to conform to this specification, but it MUST conform to the specific parts of any other specification which are called out in this specification (e.g., a conforming UI Events user agent MUST support the DOMString data type as defined in Web IDL, but need not support every method or data type defined in Web IDL in order to conform to UI Events).

This specification defines several classes of conformance for different user agents, specifications, and content authors:

Web browsers and other dynamic or interactive user agents

A dynamic or interactive user agent, referred to here as a browser (be it a Web browser, AT (Accessibility Technology) application, or other similar program), conforms to UI Events if it supports:

• the Core module defined in [DOM3 Core]
• the Event dispatch and DOM event flow mechanism
• all the interfaces and events with their associated methods, attributes, and semantics defined in this specification with the exception of those marked as deprecated (a conforming user agent MAY implement the deprecated interfaces, events, or APIs for backwards compatibility, but is not required to do so in order to be conforming)
• the complete set of key and code values defined in [DOM3 key Values] and [DOM3 code Values] (subject to platform availability), and
• all other normative requirements defined in this specification.

A conforming browser MUST dispatch events appropriate to the given EventTarget when the conditions defined for that event type have been met.

A browser conforms specifically to UI Events if it implements the interfaces and related event types specified in Event Types.

A conforming browser MUST support scripting, declarative interactivity, or some other means of detecting and dispatching events in the manner described by this specification, and MUST support the APIs specified for that event type.

In addition to meeting all other conformance criteria, a conforming browser MAY implement features of this specification marked as deprecated, for backwards compatibility with existing content, but such implementation is discouraged.

A conforming browser MAY also support features not found in this specification, but which use the Event dispatch and DOM event flow mechanism, interfaces, events, or other features defined in this specification, and MAY implement additional interfaces and event types appropriate to that implementation. Such features can be later standardized in future specifications.

A browser which does not conform to all required portions of this specification MUST NOT claim conformance to UI Events. Such an implementation which does conform to portions of this specification MAY claim conformance to those specific portions.

A conforming browser MUST also be a conforming implementation of the IDL fragments in this specification, as described in the Web IDL specification [WEBIDL].

Authoring tools

A content authoring tool conforms to UI Events if it produces content which uses the event types and Event dispatch and DOM event flow model, consistent in a manner as defined in this specification.

A content authoring tool MUST NOT claim conformance to UI Events for content it produces which uses features of this specification marked as deprecated in this specification.

A conforming content authoring tool SHOULD provide to the content author a means to use all event types and interfaces appropriate to all host languages in the content document being produced.

Content authors and content

A content author creates conforming UI Events content if that content uses the event types and Event dispatch and DOM event flow model, consistent in a manner as defined in this specification.

A content author SHOULD NOT use features of this specification marked as deprecated, but SHOULD rely instead upon replacement mechanisms defined in this specification and elsewhere.

Conforming content MUST use the semantics of the interfaces and event types as described in this specification.

Note

Authoring Note: Content authors are advised to follow best practices as described in accessibility and internationalization guideline specifications.

Specifications and host languages

A specification or host language conforms to UI Events if it references and uses the Event dispatch and DOM event flow mechanism, interfaces, events, or other features defined in [DOM4], and does not extend these features in incompatible ways.

A specification or host language conforms specifically to UI Events if it references and uses the interfaces and related event types specified in Event Types. A conforming specification MAY define additional interfaces and event types appropriate to that specification, or MAY extend the UI Events interfaces and event types in a manner that does not contradict or conflict with the definitions of those interfaces and event types in this specification.

Specifications or host languages which reference UI Events SHOULD NOT use or recommend features of this specification marked as deprecated, but SHOULD use or recommend the indicated replacement for that the feature (if available).

1.3 Stylistic Conventions

This specification follows the Proposed W3C Specification Conventions, with the following supplemental additions:

Key and character values

• Names of key values are shown as: '=' (e.g., the value of KeyboardEvent.key).
• Names of key codes are shown as: 'Equal' (e.g., the value of KeyboardEvent.code).
• Character values of keys are shown as: '\u003d' (e.g., the code point of the key value).
• Glyphs representing character values are shown as: '=' (e.g., the key cap or font associated with a character value).

In addition, certain terms are used in this specification with particular meanings. The term implementation applies to a browser, content authoring tool, or other user agent that implements this specification, while a content author is a person who writes script or code that takes advantage of the interfaces, methods, attributes, events, and other features described in this specification in order to make Web applications, and a user is the person who uses those Web applications in an implementation.

3.1 Event dispatch and DOM event flow

This section defines the event dispatch mechanism of the event model defined in this specification. Applications MAY dispatch event objects using the EventTarget.dispatchEvent() method, and implementations MUST dispatch event objects as if through this method. The behavior of this method depends on the event flow associated with the underlying object. An event flow describes how event objects propagate through a data structure. As an example, when an event object is dispatched to an element in an XML document, the object propagates through parts of the document, as determined by the DOM event flow which is defined at the end of this section.

Event objects are dispatched to an event target. At the beginning of the dispatch, implementations MUST first determine the event object's propagation path.

The propagation path MUST be an ordered list of current event targets through which the event object MUST pass. For DOM implementations, the propagation path MUST reflect the hierarchical tree structure of the document. The last item in the list MUST be the event target. The preceding items in the list are referred to as the target's ancestors, and the immediately preceding item as the target's parent. Once determined, the propagation path MUST NOT be changed. For DOM implementations, this applies even if an element in the propagation path is moved within the DOM or removed from the DOM.

Note that event listeners are not copied over when Node are copied using methods such as Node.cloneNode or Range.cloneContents [DOM Range].

Exceptions thrown inside event listeners MUST NOT stop the propagation of the event or affect the propagation path. The exception itself MUST NOT propagate outside the scope of the event handler.

var e = document.createEvent("Event");
e.initEvent("myevent", false, false);
var target = document.createElement("div");
target.addEventListener("myevent", function () {
   throw "Error";
});
target.dispatchEvent(e); // Causes the event listener to throw an exception...
// The previously thrown exception doesn't affect the code that follows:
console.log("Exceptions? No problem");

As the next step, the event object MUST complete one or more event phases. This specification defines three event phases: capture phase, target phase and bubble phase. Event objects complete these phases in the specified order using the partial propagation paths as defined below. A phase MUST be skipped if it is not supported, or if the event object's propagation has been stopped. For example, if the Event.bubbles attribute is set to false, the bubble phase will be skipped, and if Event.stopPropagation() has been called prior to the dispatch, all phases MUST be skipped.

1. The capture phase: The event object MUST propagate through the target's ancestors from the Window to the target's parent. This phase is also known as the capturing phase. Event listeners registered for this phase MUST handle the event before it reaches its target.
2. The target phase: The event object MUST arrive at the event object's event target. This phase is also known as the at-target phase. Event listeners registered for this phase MUST handle the event once it has reached its target. If the event type indicates that the event MUST NOT bubble, the event object MUST halt after completion of this phase.
3. The bubble phase: The event object propagates through the target's ancestors in reverse order, starting with the target's parent and ending with the Window. This phase is also known as the bubbling phase. Event listeners registered for this phase MUST handle the event after it has reached its target.

Implementations MUST let event objects accomplish an event phase by applying the following steps while there are pending event targets in the partial propagation path for this phase and the event object's propagation has not been stopped through Event.stopPropagation().

First, the implementation MUST determine the current target. This MUST be the next pending event target in the partial propagation path, starting with the first. From the perspective of an event listener this MUST be the event target the listener has been registered on.

Next, the implementation MUST determine the current target's candidate event listeners. This MUST be the list of all event listeners that have been registered on the current target in their order of registration. [HTML5] defines the ordering of listeners registered through event handler attributes. Once determined, the candidate event listeners MUST NOT be changed. Adding or removing listeners does not affect the current target's candidate event listeners.

Finally, the implementation MUST process all candidate event handlers in order and trigger each handler if all the following conditions are met:

• The event object's immediate propagation has not been stopped.
• The listener has been registered for this event phase.
• The listener has been registered for this event type.

In the production of the propagation path, the event propagates from the Window to the document object during the capture phase, and from the document object to the Window during the bubble phase.

After an event completes all the phases of its propagation path, its Event.currentTarget MUST be set to null and the Event.eventPhase MUST be set to 0 (NONE). All other attributes of the Event (or interface derived from Event) are unchanged (including the Event.target attribute, which MUST continue to reference the event target).

The model defined above MUST be applied regardless of the specific event flow associated with an event target. Each event flow MUST define how the propagation path MUST be determined and which event phases are supported. The DOM event flow is an application of this model: the propagation path for a Node object MUST be determined by its Node.parentNode chain, and if applicable, the document's containing Window. All events accomplish the capture and target phases. Whether an event accomplishes the bubble phase MUST be defined individually for each event type. An alternate application of this model can be found in [DOM3 Load and Save].

Implementations of the DOM event model MUST be reentrant. Event listeners MAY perform actions that cause additional events to be dispatched. Such events are handled in a synchronous manner, the event propagation that causes the event listener to be triggered MUST resume only after the event dispatch of the new event is completed.

3.2 Default actions and cancelable events

Events are typically dispatched by the implementation as a result of a user action, in response to the completion of a task, or to signal progress during asynchronous activity (such as a network request). Some events can be used to control the behavior that the implementation MAY take next (or undo an action that the implementation already took). Events in this category are said to be cancelable and the behavior they cancel is called their default action. Cancelable event objects can be associated with one or more default actions. To cancel an event, call the Event.preventDefault() method.

Default actions SHOULD be performed after the event dispatch has been completed, but in exceptional cases MAY also be performed immediately before the event is dispatched.

When an event is canceled, then the conditional default actions associated with the event MUST be skipped (or as mentioned above, if the default actions are carried out before the dispatch, their effect MUST be undone). Whether an event object is cancelable MUST be indicated by the Event.cancelable attribute. Event.preventDefault() stops all related default actions of an event object. The Event.defaultPrevented attribute indicates whether an event has already been canceled (e.g., by a prior event listener). If the DOM application itself initiated the dispatch, then the return value of the EventTarget.dispatchEvent() method indicates whether the event object was cancelled.

This specification does not offer features to programatically query if an event object has any default action associated with it, or to associate new default actions with an event object. Other specifications SHOULD define what default actions, if any, are associated with certain event objects. Further, implementations MAY associate default actions with events as necessary and appropriate for that implementation.

3.3 Synchronous and asynchronous events

Events MAY be dispatched either synchronously or asynchronously.

Events which are synchronous (sync events) MUST be treated as if they are in a virtual queue in a first-in-first-out model, ordered by sequence of temporal occurrence with respect to other events, to changes in the DOM, and to user interaction. Each event in this virtual queue MUST be delayed until the previous event has completed its propagation behavior, or been canceled. Some sync events are driven by a specific device or process, such as mouse button events. These events are governed by the event order algorithms defined for that set of events, and a user agent MUST dispatch these events in the defined order.

Events which are asynchronous (async events) MAY be dispatched as the results of the action are completed, with no relation to other events, to other changes in the DOM, nor to user interaction.

3.4 Trusted events

Events that are generated by the user agent, either as a result of user interaction, or as a direct result of changes to the DOM, are trusted by the user agent with privileges that are not afforded to events generated by script through the DocumentEvent.createEvent("Event") method, modified using the Event.initEvent() method, or dispatched via the EventTarget.dispatchEvent() method. The isTrusted attribute of trusted events has a value of true, while untrusted events have a isTrusted attribute value of false.

Most untrusted events SHOULD NOT trigger default actions, with the exception of the click event. This event always triggers the default action, even if the isTrusted attribute is false (this behavior is retained for backward-compatibility). All other untrusted events MUST behave as if the Event.preventDefault() method had been called on that event.

3.5 Activation triggers and behavior

Certain event targets (such as a link or button element) MAY have associated activation behavior (such a following a link) that implementations perform in response to an activation trigger (such as clicking a link).

A host language SHOULD indicate which, if any, elements have activation behavior, describe appropriate activation triggers, and define the result of that activation behavior. An implementation which supports a host language SHOULD initiate these activation behavior when the associated activation trigger occurs.

An activation trigger is a user action or an event which indicates to the implementation that an activation behavior SHOULD be initiated. User-initiated activation triggers include clicking a mouse button on an activatable element, pressing the 'Enter' key when an activatable element has focus, or pressing a key that is somehow linked to an activatable element (a hotkey or access key) even when that element does not have focus. Event-based activation triggers MAY include timer-based events that activate an element at a certain clock time or after a certain time period has elapsed, progress events after a certain action has been completed, or many other condition-based or state-based events.

In some cases, a host language MAY define attributes or even attribute values which add to or change the native activation trigger or activation behavior of an element. For example, ARIA [ARIA] defines values for the role attribute that add semantics to the element to which it is applied, for purposes of enhanced accessibility. In such cases, if the host language does not explicitly define the activation trigger or activation behavior, the content author MUST provide the mechanics of the activation trigger (via an event listener) or activation behavior (such as calling an ECMAScript function) for that element when applying that attribute or attribute value.

3.6 Event exceptions

This section is informative.

Event operations can throw a DOMException as specified in their method descriptions.

The following DOMException types are used in this specification.

3.7 Constructing Mouse and Keyboard Events

Generally, when a constructor of an Event interface, or of an interface inherited from the Event interface, is invoked, the steps described in DOM4 [DOM4] should be followed. However the KeyboardEvent and MouseEvent interfaces provide additional dictionary members for initializing the internal state of the Event object's key modifiers: specifically, the internal state queried for using the KeyboardEvent.getModifierState() and MouseEvent.getModifierState() methods. This section supplements the DOM4 steps for intializing a new Event object with these optional modifier states.

For the purposes of constructing a KeyboardEvent, MouseEvent, or object derived from these objects using the algorithm below, all KeyboardEvent, MouseEvent, and derived ojects have internal key modifier state which can be set and retreived using the key modifier names: 'AltGraph' 'CapsLock' 'Fn' 'FnLock' 'Hyper' 'NumLock' 'OS' 'ScrollLock' 'Super' 'Symbol' and 'SymbolLock'.

The following steps supplement the algorithm defined for constructing events in DOM4:

1. If the Event being constructed is a KeyboardEvent or MouseEvent object or an object that derives from either of these, and a EventModifierInit argument was provided to the constructor, then run the following sub-steps:
   1. For each EventModifierInit argument, if the dictionary member begins with the string "keyModifierState", then let the key modifier name be the dictionary member's name excluding the prefix "keyModifierState", and set the Event object's internal key modifier state that matches the key modifier name to the corresponding value.

4.1 List of Event Types

Each event MUST be associated with a type, called event type and available as the type attribute on the event object. The event type MUST be of type DOMString.

Depending on the level of DOM support, or the devices used for display (e.g., screen) or interaction (e.g., mouse, keyboard, touch screen, or voice), these event types can be generated by the implementation. When used with an [XML 1.0] or [HTML5] application, the specifications of those languages MAY restrict the semantics and scope (in particular the possible event targets) associated with an event type. Refer to the specification defining the language used in order to find those restrictions or to find event types that are not defined in this document.

The following table provides an informative summary of the event types defined in this specification.

For a list of events which are deprecated in this specification, see the Legacy Event Types appendix at the end of this document.

5.1 User Interface Event Types

The User Interface event module contains basic event types associated with user interfaces and document manipulation.

[Constructor(DOMString type, optional UIEventInit eventInitDict)]
interface UIEvent : Event {
    readonly    attribute Window? view;
    readonly    attribute long    detail;
};

dictionary UIEventInit : EventInit {
    Window? view = null;
    long    detail = 0;
};

The User Interface event types are listed below. Some of these events use the UIEvent interface if generated from a user interface, but the Event interface otherwise, as detailed in each event.

5.2 Focus Event Types

[Constructor(DOMString typeArg, optional FocusEventInit focusEventInitDict)]
interface FocusEvent : UIEvent {
    readonly    attribute EventTarget? relatedTarget;
};

dictionary FocusEventInit : UIEventInit {
    EventTarget? relatedTarget = null;
};

The Focus event types are listed below.

5.3 Mouse Event Types

The mouse event module originates from the [HTML 4.01] onclick, ondblclick, onmousedown, onmouseup, onmouseover, onmousemove, and onmouseout attributes. This event module is specifically designed for use with pointing input devices, such as a mouse or a trackball.

[Constructor(DOMString typeArg, optional MouseEventInit mouseEventInitDict)]
interface MouseEvent : UIEvent {
    readonly    attribute long           screenX;
    readonly    attribute long           screenY;
    readonly    attribute long           clientX;
    readonly    attribute long           clientY;
    readonly    attribute boolean        ctrlKey;
    readonly    attribute boolean        shiftKey;
    readonly    attribute boolean        altKey;
    readonly    attribute boolean        metaKey;
    readonly    attribute short          button;
    readonly    attribute EventTarget?   relatedTarget;
    // Introduced in this specification
    readonly    attribute unsigned short buttons;
    boolean getModifierState (DOMString keyArg);
};

dictionary MouseEventInit : EventModifierInit {
    long           screenX = 0;
    long           screenY = 0;
    long           clientX = 0;
    long           clientY = 0;
    short          button = 0;
    unsigned short buttons = 0;
    EventTarget?   relatedTarget = null;
};

Implementations MUST maintain the current click count when generating mouse events. This MUST be a non-negative integer indicating the number of consecutive clicks of a pointing device button within a specific time. The delay after which the count resets is specific to the environment configuration.

dictionary EventModifierInit : UIEventInit {
    boolean ctrlKey = false;
    boolean shiftKey = false;
    boolean altKey = false;
    boolean metaKey = false;
    boolean modifierAltGraph = false;
    boolean modifierCapsLock = false;
    boolean modifierFn = false;
    boolean modifierFnLock = false;
    boolean modifierHyper = false;
    boolean modifierNumLock = false;
    boolean modifierOS = false;
    boolean modifierScrollLock = false;
    boolean modifierSuper = false;
    boolean modifierSymbol = false;
    boolean modifierSymbolLock = false;
};

5.3.3 Mouse Event Order

Certain mouse events defined in this specification MUST occur in a set order relative to one another. The following shows the event sequence that MUST occur when a pointing device's cursor is moved over an element:

	Event Name	Element	Notes
1.	mousemove
			Pointing device is moved into element A...
2.	mouseover	A
3.	mouseenter	A
4.	mousemove	A	Multiple events
			Pointing device is moved out of element A...
5.	mouseout	A
6.	mouseleave	A

When a pointing device is moved into an element A, and then into a nested element B and then back out again, the following sequence of events MUST occur:

	Event Name	Element	Notes
1.	mousemove
			Pointing device is moved into element A...
2.	mouseover	A
3.	mouseenter	A
4.	mousemove	A	Multiple events
			Pointing device is moved into nested element B...
5.	mouseout	A
6.	mouseover	B
7.	mouseenter	B
8.	mousemove	B	Multiple events
			Pointing device is moved from element B into A...
9.	mouseout	B
10.	mouseleave	B
11.	mouseover	A
12.	mousemove	A	Multiple events
			Pointing device is moved out of element A...
13.	mouseout	A
14.	mouseleave	A

Sometimes elements can be visually overlapped using CSS. In the following example, three elements labeled A, B, and C all have the same dimensions and absolute position on a web page. Element C is a child of B, and B is a child of A in the DOM:

When the pointing device is moved from outside the element stack to the element labeled C and then moved out again, the following series of events MUST occur:

	Event Name	Element	Notes
1.	mousemove
			Pointing device is moved into element C, the topmost element in the stack
2.	mouseover	C
3.	mouseenter	A
4.	mouseenter	B
5.	mouseenter	C
6.	mousemove	C	Multiple events
			Pointing device is moved out of element C...
7.	mouseout	C
8.	mouseleave	C
9.	mouseleave	B
10.	mouseleave	A

Note

Note: The mouseover/mouseout events are only fired once, while mouseenter/mouseleave events are fired three times (once to each element).

The following is the typical sequence of events when a button associated with a pointing device (e.g., a mouse button or trackpad) is pressed and released over an element:

	Event Name	Notes
1.	mousedown
2.	mousemove	OPTIONAL, multiple events, some limits
3.	mouseup
4.	click
5.	mousemove	OPTIONAL, multiple events, some limits
6.	mousedown
7.	mousemove	OPTIONAL, multiple events, some limits
8.	mouseup
9.	click
10.	dblclick

Note

Note: The lag time, degree, distance, and number of mousemove events allowed between the mousedown and mouseup events while still firing a click or dblclick event will be implementation-, device-, and platform-specific. This tolerance can aid users that have physical disabilities like unsteady hands when these users interact with a pointing device.

Each implementation will determine the appropriate hysteresis tolerance, but in general SHOULD fire click and dblclick events when the event target of the associated mousedown and mouseup events is the same element with no mouseout or mouseleave events intervening, and SHOULD fire click and dblclick events on the nearest common inclusive ancestor when the associated mousedown and mouseup event targets are different.

If a mousedown event was targeted at an HTML document's body element, and the corresponding mouseup event was targeted at the root element, then the click event will be dispatched to the root element, since it is the nearest common inclusive ancestor.

If the event target (e.g. the target element) is removed from the DOM during the mouse events sequence, the remaining events of the sequence MUST NOT be fired on that element.

If the target element is removed from the DOM as the result of a mousedown event, no events for that element will be dispatched for mouseup, click, or dblclick, nor any default activation events. However, the mouseup event will still be dispatched on the element that is exposed to the mouse after the removal of the initial target element. Similarly, if the target element is removed from the DOM during the dispatch of a mouseup event, the click and subsequent events will not be dispatched.

The Mouse event types are listed below. In the case of nested elements, mouse event types are always targeted at the most deeply nested element. Ancestors of the targeted element MAY use bubbling to obtain notification of mouse events which occur within its descendent elements.

5.4 Wheel Event Types

Wheels are devices that can be rotated in one or more spatial dimensions, and which can be associated with a pointer device. The coordinate system depends on the environment configuration.

The deltaX, deltaY, and deltaZ attributes of WheelEvent objects indicate a measurement along their respective axes in units of pixels, lines, or pages. The reported measurements are provided after an environment-specific algorithm translates the actual rotation/movement of the wheel device into the appropriate values and units.

The sign (positive or negative) of the values of the deltaX, deltaY, and deltaZ attributes MUST be consistent between multiple dispatches of the wheel event while the motion of the actual wheel device is rotating/moving in the same direction. If a user agent scrolls as the default action of the wheel event then the sign of the delta SHOULD be given by a right-hand coordinate system where positive X, Y, and Z axes are directed towards the right-most edge, bottom-most edge, and farthest depth (away from the user) of the document, respectively.

[Constructor(DOMString typeArg, optional WheelEventInit wheelEventInitDict)]
interface WheelEvent : MouseEvent {
    // DeltaModeCode
    const unsigned long DOM_DELTA_PIXEL = 0x00;
    const unsigned long DOM_DELTA_LINE = 0x01;
    const unsigned long DOM_DELTA_PAGE = 0x02;
    readonly    attribute double        deltaX;
    readonly    attribute double        deltaY;
    readonly    attribute double        deltaZ;
    readonly    attribute unsigned long deltaMode;
};

dictionary WheelEventInit : MouseEventInit {
    double        deltaX = 0.0;
    double        deltaY = 0.0;
    double        deltaZ = 0.0;
    unsigned long deltaMode = 0;
};

The Wheel event types are listed below.

5.5 Keyboard Event Types

Keyboard events are device dependent, i.e., they rely on the capabilities of the input devices and how they are mapped in the operating systems. Refer to Keyboard events and key values for more details, including examples on how Keyboard Events are used in combination with Composition Events. Depending on the character generation device, keyboard events might not be generated.

[Constructor(DOMString typeArg, optional KeyboardEventInit keyboardEventInitDict)]
interface KeyboardEvent : UIEvent {
    // KeyLocationCode
    const unsigned long DOM_KEY_LOCATION_STANDARD = 0x00;
    const unsigned long DOM_KEY_LOCATION_LEFT = 0x01;
    const unsigned long DOM_KEY_LOCATION_RIGHT = 0x02;
    const unsigned long DOM_KEY_LOCATION_NUMPAD = 0x03;
    readonly    attribute DOMString     key;
    readonly    attribute DOMString     code;
    readonly    attribute unsigned long location;
    readonly    attribute boolean       ctrlKey;
    readonly    attribute boolean       shiftKey;
    readonly    attribute boolean       altKey;
    readonly    attribute boolean       metaKey;
    readonly    attribute boolean       repeat;
    readonly    attribute boolean       isComposing;
    boolean getModifierState (DOMString keyArg);
};

dictionary KeyboardEventInit : EventModifierInit {
    DOMString     key = "";
    DOMString     code = "";
    unsigned long location = 0;
    boolean       repeat = false;
    boolean       isComposing = false;
};

The keyboard event types are listed below.

5.6 Composition Event Types

Composition Events provide a means for inputing text in a supplementary or alternate manner than by Keyboard Events, in order to allow the use of characters that might not be commonly available on keyboard. For example, Composition Events might be used to add accents to characters despite their absence from standard US keyboards, to build up logograms of many Asian languages from their base components or categories, to select word choices from a combination of key presses on a mobile device keyboard, or to convert voice commands into text using a speech recognition processor. Refer to Keyboard events and key values for examples on how Composition Events are used in combination with keyboard events.

Conceptually, a composition session consists of one compositionstart event, one or more compositionupdate events, and one compositionend event, with the value of the data attribute persisting between each stage of this event chain during each session.

Not all IME systems or devices expose the necessary data to the DOM, so the active composition string (the Reading Window or candidate selection menu option) might not be available through this interface, in which case the selection MAY be represented by the empty string.

[Constructor(DOMString typeArg, optional CompositionEventInit compositionEventInitDict)]
interface CompositionEvent : UIEvent {
    readonly    attribute DOMString data;
};

dictionary CompositionEventInit : UIEventInit {
    DOMString data = "";
};

6.1 Keyboard Input

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:

• Mechanical layout: the dimensions, size, and placement of the physical keys on the keyboard
• Visual markings: the labels (or legends) that mark each key
• Functional mapping: the abstract key-value association of each key.

This specification only defines the functional mapping, in terms of key values and code values, but briefly describes key legends for background.

6.2 Key codes

A key code is an attribute of a keyboard event that can be used to identify the physical key associated with the keyboard event. It is similar to USB Usage IDs in that it provides a low-level value (similar to a scancode) that is vendor-neutral.

The primary purpose of the code attribute is to provide a consistent and coherent way to identify keys based on their physical location. In addition, it also provides a stable name (unaffected by the current keyboard state) that uniquely identifies each key on the keyboard.

The list of valid code values is defined in the DOM Level 3 KeyboardEvent code Values Specification [DOM3 code Values].

6.3 Keyboard Event key Values

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

The list of valid key values is defined in the DOM Level 3 KeyboardEvent key Values Specification [DOM3 key Values].

Key values can be used to detect the value of a key which has been pressed, using the KeyboardEvent.key attribute. 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.

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), 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 and 'O' in a shifted state. Because a user can map their keyboard to an arbitrary custom configuration, the content author is encouraged not to 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 is encouraged instead to use the value of the KeyboardEvent.key attribute. For example, the Standard "102" Keyboard layout depicted in [DOM3 code Values] 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 might 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).

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 '\u00D7') or the Latin small letter 'x' (due to the lack of a multiplication key on many keyboards 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.

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 {
   // ...
}

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 {
   // ...
}