Pointer Events
Level 4
More details about this document
- This version:
- https://www.w3.org/TR/2026/WD-pointerevents4-20260225/
- Latest published version:
- https://www.w3.org/TR/pointerevents4/
- Latest editor's draft:
- https://w3c.github.io/pointerevents/
- History:
- https://www.w3.org/standards/history/pointerevents4/
- Commit history
- Test suite:
- https://wpt.fyi/pointerevents/
- Latest Recommendation:
- https://www.w3.org/TR/pointerevents2
- Editors:
- Former editors:
- Feedback:
- GitHub w3c/pointerevents (pull requests, new issue, open issues)
- public-pointer-events@w3.org with subject line [pointerevents4] … message topic … (archives)
- Browser support:
- caniuse.com
Copyright © 2026 World Wide Web Consortium. W3C® liability, trademark and permissive document license rules apply.
Abstract
The Pointer Events specification defines a unified hardware-agnostic framework for handling input from various devices, including mice, touchscreens, and pens/styluses. By providing a single set of events (e.g., pointerdown, pointermove, pointerup), it allows developers to support diverse input methods without writing device-specific logic for each.
This specification also defines Mouse and Wheel Events, as well as a mapping to fire Mouse Events for other pointer device types.
Status of This Document
This section describes the status of this document at the time of its publication. A list of current W3C publications and the latest revision of this technical report can be found in the W3C standards and drafts index.
This specification is an update to [PointerEvents3] specification. It also includes the Mouse and Wheel Events, previously in the [UIEVENTS] specification.
This revision includes new features:
persistentDeviceIdto provide a stable identifier for input devices across multiple interactions.- new CSS
touch-actionvalues:pan-left,pan-right,pan-up,pan-down
This document was published by the Pointer Events Working Group as a Working Draft using the Recommendation track.
Publication as a Working Draft does not imply endorsement by W3C and its Members.
This is a draft document and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to cite this document as other than a work in progress.
This document was produced by a group operating under the W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent that the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.
This document is governed by the 18 August 2025 W3C Process Document.
This section is non-normative.
Today, most [HTML] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [UIEVENTS] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens and pen input. Event types have been proposed for handling each of these forms of input individually. However, that approach often incurs unnecessary duplication of logic and event handling overhead when adding support for a new input type. This often creates a compatibility problem when content is written with only one device type in mind. Additionally, for compatibility with existing mouse-based content, most user agents fire Mouse Events for all input types. This makes it ambiguous whether a Mouse Event represents an actual mouse device or is being produced from another input type for compatibility, which makes it hard to code to both device types simultaneously.
To reduce the cost of coding to multiple input types and also to help with the above described ambiguity with Mouse Events, this specification defines a more abstract form of input, called a pointer. A pointer can be any point of contact on the screen made by a mouse cursor, pen, touch (including multi-touch), or other pointing input device. This model makes it easier to write sites and applications that work well no matter what hardware the user has. For scenarios when device-specific handling is desired, this specification also defines properties for inspecting the device type which produced the event. The primary goal is to provide a single set of events and interfaces that allow for easier authoring for cross-device pointer input while still allowing for device-specific handling only when necessary for an augmented experience.
An additional key goal is to enable multi-threaded user agents to handle direct manipulation actions for panning and zooming (for instance, with a finger or stylus on a touchscreen), without blocking on script execution.
While this specification defines a unified event model for a variety of pointer inputs, this model does not cover other forms of input such as keyboards or keyboard-like interfaces (for instance, a screen reader or similar assistive technology running on a touchscreen-only device, which allows users sequential navigation through focusable controls and elements). While user agents might choose to also generate pointer events in response to these interfaces, this scenario is not covered in this specification.
In the first instance, authors are encouraged to provide equivalent functionality for all forms of input by responding to high-level events such as focus, blur and click. However, when using low-level events (such as Pointer Events), authors are encouraged to ensure that all types of input are supported. In the case of keyboards and keyboard-like interfaces, this might require the addition of explicit keyboard event handling. See Keyboard Accessible [WCAG22] for further details.
The events for handling generic pointer input look a lot like those for mouse: pointerdown, pointermove, pointerup, pointerover, pointerout, and so on. This facilitates easy content migration from Mouse Events to Pointer Events.
Pointer Events provide all the usual properties present in Mouse Events (including client coordinates, target element, button states) in addition to new properties for other forms of input, such as pressure, contact geometry, tilt. Authors can easily code to Pointer Events to share logic between different input types where it makes sense, and customize for a particular type of input only where necessary to get the best experience.
While Pointer Events are sourced from a variety of input devices, they are not defined as being generated from some other set of device-specific events. While possible and encouraged for compatibility, this spec does not require other device-specific events be supported (such as mouse events or touch events). A user agent could support pointer events without supporting any other device events. For compatibility with content written to mouse-specific events, this specification does provide an optional section describing how to generate compatibility mouse events based on pointer input from devices other than a mouse.
This specification does not provide any advice on the expected behavior of user agents that support both Touch Events (as defined in [TOUCH-EVENTS]) and Pointer Events. For more information on the relationship between these two specifications, see the Touch Events Community Group.
As well as sections marked as non-normative, all authoring guidelines, diagrams, examples, and notes in this specification are non-normative. Everything else in this specification is normative.
The key words MAY, MUST, MUST NOT, OPTIONAL, and SHOULD in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
This section is non-normative.
The following are basic examples that demonstrate how some of the APIs in this specification might be used by authors. Further, more specific examples are provided in the relevant sections of this document.
/* Bind to either Pointer Events or traditional touch/mouse */
if (window.PointerEvent) {
// if Pointer Events are supported, only listen to pointer events
target.addEventListener("pointerdown", function(e) {
// if necessary, apply separate logic based on e.pointerType
// for different touch/pen/mouse behavior
...
});
...
} else {
// traditional touch/mouse event handlers
target.addEventListener('touchstart', function(e) {
// prevent compatibility mouse events and click
e.preventDefault();
...
});
...
target.addEventListener('mousedown', ...);
...
}
// additional event listeners for keyboard handling
...
window.addEventListener("pointerdown", detectInputType);
function detectInputType(event) {
switch(event.pointerType) {
case "mouse":
/* mouse input detected */
break;
case "pen":
/* pen/stylus input detected */
break;
case "touch":
/* touch input detected */
break;
default:
/* pointerType is empty (could not be detected)
or UA-specific custom type */
}
}
<div style="position:absolute; top:0px; left:0px; width:100px;height:100px;"></div>
<script>
window.addEventListener("pointerdown", checkPointerSize);
function checkPointerSize(event) {
event.target.style.width = event.width + "px";
event.target.style.height = event.height + "px";
}
</script>
const event1 = new PointerEvent("pointerover",
{ bubbles: true,
cancelable: true,
composed: true,
pointerId: 42,
pointerType: "pen",
clientX: 300,
clientY: 500
});
eventTarget.dispatchEvent(event1);
let pointerEventInitDict =
{
bubbles: true,
cancelable: true,
composed: true,
pointerId: 42,
pointerType: "pen",
clientX: 300,
clientY: 500,
};
const p1 = new PointerEvent("pointermove", pointerEventInitDict);
pointerEventInitDict.clientX += 10;
const p2 = new PointerEvent("pointermove", pointerEventInitDict);
pointerEventInitDict.coalescedEvents = [p1, p2];
const event2 = new PointerEvent("pointermove", pointerEventInitDict);
eventTarget.dispatchEvent(event2);
<div style="position:absolute; top:0px; left:0px; width:100px;height:100px;"></div>
<script>
window.addEventListener("pointerdown", assignPenColor);
window.addEventListener("pointermove", assignPenColor);
const colorMap = new Map();
function assignPenColor(event) {
const uniqueId = event.persistentDeviceId;
// Check if a unique Id exists.
if (uniqueId == 0) {
return;
}
// Check if a color has been assigned to the device.
if (map.has(uniqueId)) {
return;
}
// Assign a color to the device.
let newColor = getNewColor();
map.set(uniqueId, newColor);
return newColor;
}
function getNewColor() {
/* return some color value */
}
</script>
The mouse event module originates from the [HTML401] 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.
Introduced in DOM Level 2, modified in this specification.
The MouseEvent interface provides specific contextual information associated with Mouse events.
In the case of nested elements, mouse events are always targeted at the most deeply nested element.
Ancestors of the targeted element can use event bubbling to obtain notifications of mouse events which occur within their descendent elements.
To create an instance of the MouseEvent interface, use the MouseEvent constructor, passing an optional MouseEventInit dictionary.
When initializing MouseEvent objects using initMouseEvent, implementations can use the client coordinates clientX and clientY for calculation of other coordinates (such as target coordinates exposed by DOM Level 0 implementations or other proprietary attributes, e.g., pageX).
WebIDL[Exposed=Window]
interface MouseEvent : UIEvent {
constructor(DOMString type, optional MouseEventInit eventInitDict = {});
readonly attribute long screenX;
readonly attribute long screenY;
readonly attribute long clientX;
readonly attribute long clientY;
readonly attribute long layerX;
readonly attribute long layerY;
readonly attribute boolean ctrlKey;
readonly attribute boolean shiftKey;
readonly attribute boolean altKey;
readonly attribute boolean metaKey;
readonly attribute short button;
readonly attribute unsigned short buttons;
boolean getModifierState(DOMString keyArg);
};
screenX-
The horizontal coordinate at which the event occurred relative to the origin of the screen coordinate system.
The un-initialized value of this attribute MUST be
0. screenY-
The vertical coordinate at which the event occurred relative to the origin of the screen coordinate system.
The un-initialized value of this attribute MUST be
0. clientX-
The horizontal coordinate at which the event occurred relative to the viewport associated with the event.
The un-initialized value of this attribute MUST be
0. clientY-
The vertical coordinate at which the event occurred relative to the viewport associated with the event.
The un-initialized value of this attribute MUST be
0. layerX-
The horizontal offset from the nearest ancestor element which is a stacking context, is positioned, or paints in the positioned phase when painting a stacking context.
The un-initialized value of this attribute MUST be
0. layerY-
The vertical offset from the nearest ancestor element which is a stacking context, is positioned, or paints in the positioned phase when painting a stacking context.
The un-initialized value of this attribute MUST be
0. ctrlKey-
Refer to the
KeyboardEvent'sctrlKeyattribute.The un-initialized value of this attribute MUST be
false. shiftKey-
Refer to the
KeyboardEvent'sshiftKeyattribute.The un-initialized value of this attribute MUST be
false. altKey-
Refer to the
KeyboardEvent'saltKeyattribute.The un-initialized value of this attribute MUST be
false. metaKey-
Refer to the
KeyboardEvent'smetaKeyattribute.The un-initialized value of this attribute MUST be
false. button-
During mouse events caused by the depression or release of a mouse button,
buttonMUST be used to indicate which pointer device button changed state.The value of the
buttonattribute MUST be as follows:-
0MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text) or the un-initialized value. -
1MUST indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel). -
2MUST indicate the secondary button (in general, the right button, often used to display a context menu). -
3MUST indicate the X1 (back) button. -
4MUST indicate the X2 (forward) button.
Some pointing devices provide or simulate more button states, and values higher than
2or lower than0MAY be used to represent such buttons.NoteThe value of
buttonis not updated for events not caused by the depression/release of a mouse button. In these scenarios, take care not to interpret the value0as the left button, but rather as the default value.NoteSome default actions related to events such as
mousedownandmouseupdepend on the specific mouse button in use.The un-initialized value of this attribute MUST be
0. -
buttons-
During any mouse events,
buttonsMUST be used to indicate which combination of mouse buttons are currently being pressed, expressed as a bitmask.NoteThough similarly named, the values for the
buttonsattribute and thebuttonattribute are very different. The value ofbuttonis assumed to be valid duringmousedown/mouseupevent handlers, whereas thebuttonsattribute reflects the state of the mouse's buttons for any trustedMouseEventobject (while it is being dispatched), because it can represent the "no button currently active" state (0).The value of the
buttonsattribute MUST be as follows:0MUST indicate no button is currently active.1MUST indicate the primary button of the device (in general, the left button or the only button on single-button devices, used to activate a user interface control or select text).2MUST indicate the secondary button (in general, the right button, often used to display a context menu), if present.4MUST indicate the auxiliary button (in general, the middle button, often combined with a mouse wheel).
Some pointing devices provide or simulate more buttons. To represent such buttons, the value MUST be doubled for each successive button (in the binary series
8,16,32, ... ).NoteBecause the sum of any set of button values is a unique number, a content author can use a bitwise operation to determine how many buttons are currently being pressed and which buttons they are, for an arbitrary number of mouse buttons on a device. For example, the value
3indicates that the left and right button are currently both pressed, while the value5indicates that the left and middle button are currently both pressed.NoteSome default actions related to events such as
mousedownandmouseupdepend on the specific mouse button in use.The un-initialized value of this attribute MUST be
0. relatedTarget-
Used to identify a secondary
EventTargetrelated to a UI event, depending on the type of event.The un-initialized value of this attribute MUST be
null. - getModifierState(keyArg)
-
Queries the state of a modifier using a key value.
Returns
trueif it is a modifier key and the modifier is activated,falseotherwise.DOMStringkeyArg-
Refer to the
KeyboardEvent'sgetModifierState()method for a description of this parameter.
WebIDLdictionary MouseEventInit : EventModifierInit {
long screenX = 0;
long screenY = 0;
long clientX = 0;
long clientY = 0;
short button = 0;
unsigned short buttons = 0;
};
screenX-
Initializes the
screenXattribute of theMouseEventobject to the desired horizontal relative position of the mouse pointer on the user's screen.Initializing the event object to the given mouse position must not move the user's mouse pointer to the initialized position.
screenY-
Initializes the
screenYattribute of theMouseEventobject to the desired vertical relative position of the mouse pointer on the user's screen.Initializing the event object to the given mouse position must not move the user's mouse pointer to the initialized position.
clientX-
Initializes the
clientXattribute of theMouseEventobject to the desired horizontal position of the mouse pointer relative to the client window of the user's browser.Initializing the event object to the given mouse position must not move the user's mouse pointer to the initialized position.
clientY-
Initializes the
clientYattribute of theMouseEventobject to the desired vertical position of the mouse pointer relative to the client window of the user's browser.Initializing the event object to the given mouse position must not move the user's mouse pointer to the initialized position.
button-
Initializes the
buttonattribute of theMouseEventobject to a number representing the desired state of the button(s) of the mouse.NoteThe value 0 is used to represent the primary mouse button, 1 is used to represent the auxiliary/middle mouse button, and 2 to represent the right mouse button. Numbers greater than 2 are also possible, but are not specified in this document.
buttons-
Initializes the
buttonsattribute of theMouseEventobject to a number representing one or more of the button(s) of the mouse that are to be considered active.NoteThe
buttonsattribute is a bit-field. If a mask value of 1 is true when applied to the value of the bit field, then the primary mouse button is down. If a mask value of 2 is true when applied to the value of the bit field, then the right mouse button is down. If a mask value of 4 is true when applied to the value of the bit field, then the auxiliary/middle button is down.In JavaScript, to initialize the
buttonsattribute as if the right (2) and middlebutton (4) were being pressed simultaneously, the buttons value can be assigned as either:{ buttons: 2 | 4 }or:
{ buttons: 6 } relatedTarget-
The
relatedTargetshould be initialized to the element whose bounds the mouse pointer just left (in the case of amouseoverormouseenterevent) or the element whose bounds the mouse pointer is entering (in the case of amouseoutormouseleaveor focusout event). For other events, this value need not be assigned (and will default to 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.
The algorithms in this section assume that the native platform OS will provide the following:
- An event when the mouse is moved (handled by handle native mouse move)
- An event when a mouse button is pressed (handled by handle native mouse down)
- An event when a mouse button is released (handled by handle native mouse up)
- A way to identify when a mouse button press should be interpreted as a "click" (handled by handle native mouse click)
- For example, as a flag or as a separate event
- If a separate "click" event is fired, then the native OS will fire it immediately after the corresponding "mouse up" event, with no intervening mouse-related events
- A way to identify when a mouse click is a "double click" (handled by handle native mouse double click)
For these events, the OS will be able to provide the following info:
- The x,y mouse coordinates relative to the native OS desktop
- The x,y mouse coordinates relative to the UA's window viewport
- Which keyboard modifiers are currently being held
This section needs to be revised.
Generally, when a constructor of an Event interface, or of an interface inherited from the Event interface, is invoked, the steps described in [DOM] should be followed. However the 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 getModifierState() methods. This section supplements the [DOM] steps for intializing a new MouseEvent object with these optional modifier states.
For the purposes of constructing a MouseEvent, or object derived from these objects using the algorithm below, all MouseEvent, and derived objects have internal key modifier state which can be set and retrieved using the key modifier names described in the Modifier Keys table in [UIEvents-Key].
The following steps supplement the algorithm defined for constructing events in [DOM]:
-
If the
Eventbeing constructed is aMouseEventobject or an object that derives from it, and aEventModifierInitargument was provided to the constructor, then run the following sub-steps:-
For each
EventModifierInitargument, if the dictionary member begins with the string"modifier", then let the key modifier name be the dictionary member's name excluding the prefix"modifier", and set theEventobject's internal key modifier state that matches the key modifier name to the corresponding value.
-
For each
This section needs to be revised.
The UA must maintain the following values that are shared for the entire User Agent.
A mouse button bitmask that tracks the current state of the mouse buttons.
The UA must maintain the following values that are shared for the Window.
A last mouse element value (initially undefined) that keeps track of the last Element that we sent a MouseEvent to.
A last mouse DOM path value (initially empty) that contains a snapshot of the ancestors Elements of the last mouse element when the most recent mouse event was sent.
This section needs to be revised.
A MouseEvent has the following internal flags that are used to track the state of various modifier keys:
shift flag,
control flag,
alt flag,
altgraph flag,
and meta flag.
These flags are set if the corresponding modifier key was pressed at the time
of the mouse event.
This section needs to be revised.
- Let pos be the x,y coordinates relative to the viewport
- Return [CSSOM-View]'s
elementFromPoint()with pos (the frontmost DOM element at pos)NoteTo account for inert or disabled elements. this should call
elementsFromPoint()and reject invalid elements.
4.2.6 initialize a MouseEvent
This section needs to be revised.
To initialize a MouseEvent with event, eventType and eventTarget, bubbles, and cancelable, run the following steps:
- Initialize a UIEvent with event, eventType, eventTarget, bubbles and cancelable.
-
Set event.
screenXto the x-coordinate of the position where the event occurred relative to the origin of the desktop -
Set event.
screenYto the y-coordinate of the position where the event occurred relative to the origin of the desktop -
Set event.
clientXto the x-coordinate of the position where the event occurred relative to the origin of the viewport -
Set event.
clientYto the y-coordinate of the position where the event occurred relative to the origin of the viewport - Set mouse event modifiers with event
-
Set event.
buttonto 0 -
Set event.
buttonsto mouse button bitmask -
Initialize PointerLock attributes for MouseEvent with event
Issue 1
We should provide a hook for PointerLock instead of hardcoding it here.
This section needs to be revised.
- Let event be the
MouseEventto update - Set event's shift flag if key modifier state includes "Shift", unset it otherwise
- Set event's control flag if key modifier state includes "Control", unset it otherwise
- Set event's alt flag if key modifier state includes "Alt", unset it otherwise
- Set event's altgraph flag if key modifier state includes "AltGraph", unset it otherwise
- Set event's meta flag if key modifier state includes "Meta", unset it otherwise
- Set event.
shiftKeyto true if the event's shift flag is set, false otherwise - Set event.
ctrlKeyto true if the event's control flag is set, false otherwise - Set event.
altKeyto true if the event's alt flag or altgraph flag is set, false otherwise - Set event.
metaKeyto true if the event's meta flag is set, false otherwise
This section needs to be revised.
- Let eventType be a DOMString containing a valid
MouseEventtype - Let eventTarget be the
EventTargetof the event - Let bubbles be true
- Let cancelable be true
- Let event be the result of creating an event using
MouseEvent - Initialize a MouseEvent with event, eventType, eventTarget, bubbles and cancelable.
- Return event
This section needs to be revised.
- Let eventType be a DOMString containing a valid
MouseEventtype - Let eventTarget be the
EventTargetof the event - Let bubbles be "false"
- Let cancelable be "false"
- Let event be the result of creating an event using
MouseEvent - Initialize a MouseEvent with event, eventType, eventTarget, bubbles and cancelable.
- Return event
This section needs to be revised.
- Let event be the
MouseEventto initialize - Let native be the native mouse event
Editor's note
TODO.
- If event.
typeis one of [ mousedown, mouseup ], then- Let mbutton be an ID from native that identifies which mouse button was pressed
- Set event.
buttonto calculate MouseEvent button attribute with mbutton
This section needs to be revised.
- Let native be the native mousedown
- Let mbutton be an ID from native that identifies which mouse button was pressed
- Update the mouse button bitmask as follows:
- If mbutton is the primary mouse button, then set the 0x01 bit
- If mbutton is the secondary mouse button, then set the 0x02 bit
- If mbutton is the auxiliary (middle) mouse button, then set the 0x04 bit
Note
Other buttons can be added starting with 0x08 .
- Let target be hit test with viewport-relative coordinates from native
- Let event be the result of creating a cancelable MouseEvent with "mousedown", target
- Set MouseEvent attributes from native with native
- Maybe send pointerdown event with event
- Let result be dispatch event at target
- If result is true and target is a focusable area that is click focusable, then
- Run the focusing steps at target
- if mbutton is the secondary mouse button, then
- Maybe show context menu with native, target
This section needs to be revised.
- Let native be the native mouseup
Note
Other mouse events can occur between the mousedown and mouseup.
- Let mbutton be an ID from native that identifies which mouse button was pressed
- Update the mouse button bitmask as follows:
- If mbutton is the primary mouse button, then clear the 0x01 bit
- If mbutton is the secondary mouse button, then clear the 0x02 bit
- If mbutton is the auxiliary (middle) mouse button, then clear the 0x04 bit
- Let target be hit test with viewport-relative coordinates from native
- Let event be the result of creating a cancelable MouseEvent with "mouseup", target
- Set MouseEvent attributes from native with native
- Maybe send pointerup event with event
- dispatch event at target
This section needs to be revised.
- Let native be the native mouse click
Note
The platform should call this immediately after handle native mouse up for mouseups that generate clicks.
- Let target be hit test with viewport-relative coordinates from native
- Send click event with native and target.
This section needs to be revised.
- Let native be the native mousedown
- Let target be the
EventTargetof the event - Let mbutton be 1 (primary mouse button by default)
- If native is valid, then
- Let mbutton be an ID from native that identifies which mouse button was pressed
- Set eventType to "click" if mbutton is the primary mouse button, otherwise "auxclick"
- Let event be the result of creating a PointerEvent with eventType and target
- If native is valid, then
- Set MouseEvent attributes from native with event, native
- If event.
screenXis not an integer value, then round it. - If event.
screenYis not an integer value, then round it.
- dispatch event at target
Note
See pointerevents/100 for info about browsers using PointerEvents and rounded coordinates.
Editor's noteAny "default action" is handled during dispatch by triggering the activation behavior algorithm for the target. So there is no need for handle that here. However, need to verify that the existing spec handles disabled/css-pointer-events/inert/...
NoteTo handle
HTMLelement.click(), call this algorithm with native = null and target =HTMLelement.NoteTo handle keyboard-initiated clicks, call this algorithm with native = null and target = currently focused element.
This section needs to be revised.
- Let native be the native mouse double click
Note
This should be called immediately after handle native mouse click for mouse clicks that generate double clicks.
- Let mbutton be an ID from native that identifies which mouse button was pressed
- If mbutton is not the primary mouse button, then return
- Let target be hit test with viewport-relative coordinates from native
- Let event be the result of creating a PointerEvent with "dblclick" and target
- Set MouseEvent attributes from native with event, native
- If event.
screenXis not an integer value, then round it. - If event.
screenYis not an integer value, then round it. - dispatch event at target
This section needs to be revised.
- Let native be the native mouse move
Issue 2
This algorithm makes assumptions about the dispatch of PointerEvents because they are not currently specified explicitly. Once pointerevents/285 is resolved this may need to be updated.
- Let target be hit test with viewport-relative coordinates from native
- Let targetDomPath be inclusive ancestors of target
- Generate events for leaving the current element:
- If last mouse element is defined and not equal to target, then
- Let mouseout be the result of creating a cancelable MouseEvent with "mouseout" and last mouse element
Editor's note
TODO: Set mouseout attributes from native. +CSSOM attributes.
- Let mouseout be the result of creating a cancelable MouseEvent with "mouseout" and last mouse element
- Maybe send pointerout event with mouseout
- Dispatch mouseout at target
Note
Verify behavior when canceled (appears to have no effect).
- Let leaveElements be a copy of last mouse DOM path with all elements common to targetDomPath removed.
- For each element in leaveElements, do
Editor's note
Handle case where element has been deleted. Also case where it has been moved: Should the DOM mutation have triggered a mouseleave event? Should we sent it now? Should it be dropped? Need to verify what current browsers do.
- Let mouseleave be the result of creating a non-cancelable MouseEvent with "mouseleave" and element
- Set mouseleave.
Event.composed= falseNoteCheck compat: Value of event.composed. Spec says false. Chrome/Linux = true. Firefox/Linux = false.
- Maybe send pointerleave event with mouseleave
- Let result be dispatch mouseleave at element
- If last mouse element is defined and not equal to target, then
- Generate events for entering the new element:
- If target is not last mouse element, then
- Let mouseover be the result of creating a cancelable MouseEvent with "mouseover" and target
Editor's note
TODO: Set mouseout attributes from native. +CSSOM attributes.
- Maybe send pointerover event with mouseover
- Dispatch mouseout at target
Note
Need to verify behavior when canceled (appears to have no effect).
- Let enterElements be a copy of targetDomPath with all elements common to last mouse DOM path removed.
- For each element in enterElements, do
Note
Handle case where element has been deleted or moved.
- Let mouseenter be the result of creating a non-cancelable MouseEvent with "mouseenter" and element
- Set mouseenter.
Event.composed= falseNoteCheck compat: Value of event.composed. Spec says false. Chrome/Linux = true. Firefox/Linux = false.
- Maybe send pointerenter event with mouseenter
Note
Check compat for shadow DOM elements. Chrome/Linux fires this event at the element and the shadow root.
- Let result be dispatch mouseenter at element
- Set last mouse element to target
- Set last mouse DOM path to targetDomPath
- Let mouseover be the result of creating a cancelable MouseEvent with "mouseover" and target
- If target is not last mouse element, then
- Let mousemove be the result of creating a cancelable MouseEvent with "mousemove" and element
- Set PointerLock attributes for mousemove
- Maybe send pointermove event with mousemove
- Dispatch mousemove at element
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 Type | Element | Notes |
|---|---|---|---|
| 1 | mousemove
| ||
| Pointing device is moved into element A... | |||
| 2 | mouseover
| A | |
| 3 | mouseenter
| A | |
| 4 | mousemove
| A | Multiple mousemove 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 Type | Element | Notes | |
|---|---|---|---|
| 1 | mousemove
| ||
| Pointing device is moved into element A... | |||
| 2 | mouseover
| A | |
| 3 | mouseenter
| A | |
| 4 | mousemove
| A | Multiple mousemove events
|
| Pointing device is moved into nested element B... | |||
| 5 | mouseout
| A | |
| 6 | mouseover
| B | |
| 7 | mouseenter
| B | |
| 8 | mousemove
| B | Multiple mousemove events
|
| Pointing device is moved from element B into A... | |||
| 9 | mouseout
| B | |
| 10 | mouseleave
| B | |
| 11 | mouseover
| A | |
| 12 | mousemove
| A | Multiple mousemove 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 Type | 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 mousemove events
|
| Pointing device is moved out of element C... | |||
| 7 | mouseout
| C | |
| 8 | mouseleave
| C | |
| 9 | mouseleave
| B | |
| 10 | mouseleave
| A |
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 Type | 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
|
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 document element, then the click event will be dispatched
to the document element, since it is the nearest common inclusive
ancestor.
If the 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.
| Type | auxclick
|
|---|---|
| Interface | PointerEvent
|
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | Varies |
| Context (trusted events) |
|
The auxclick event type MUST be dispatched on the topmost
event target indicated by the pointer, when the user presses
down and releases the non-primary pointer button, or otherwise activates
the pointer in a manner that simulates such an action. The actuation
method of the mouse button depends upon the pointer device and the
environment configuration, e.g., it MAY depend on the screen
location or the delay between the press and release of the pointing
device button.
The auxclick event should only be fired for the non-primary pointer
buttons (i.e., when button value is not 0,
buttons value is greater than 1). The primary button
(like the left button on a standard mouse) MUST NOT fire
auxclick events. See click for a corresponding event that
is associated with the primary button.
The auxclick event MAY be preceded by the mousedown and
mouseup events on the same element, disregarding changes
between other node types (e.g., text nodes). Depending upon the
environment configuration, the auxclick event MAY be dispatched
if one or more of the event types mouseover,
mousemove, and mouseout occur between the press and
release of the pointing device button.
The default action of the auxclick event type varies
based on the target of the event and the value of the
button or buttons attributes. Typical
default actions of the auxclick event type are as follows:
- If the target has associated activation behavior, the default action MUST be to execute that activation behavior.
myLink.addEventListener("auxclick", function(e) {
if (e.button === 1) {
// This would prevent the default behavior which is for example
// opening a new tab when middle clicking on a link.
e.preventDefault();
// Do something else to handle middle button click like taking
// care of opening link or non-link buttons in new tabs in a way
// that fits the app. Other actions like closing a tab in a tab-strip
// which should be done on the click action can be done here too.
}
});
In the case of right button, the auxclick event is dispatched after
any contextmenu event. Note that some user agents swallow all input
events while a context menu is being displayed, so auxclick may not be
available to applications in such scenarios.
See Example 7 for more clarification.
myDiv.addEventListener("contextmenu", function(e) {
// This call makes sure no context menu is shown
// to interfere with page receiving the events.
e.preventDefault();
});
myDiv.addEventListener("auxclick", function(e) {
if (e.button === 2) {
// Do something else to handle right button click like opening a
// customized context menu inside the app.
}
});
| Type | click
|
|---|---|
| Interface | PointerEvent
|
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | Varies |
| Context (trusted events) |
|
The click event type MUST be dispatched on the topmost
event target indicated by the pointer, when the user presses
down and releases the primary pointer button, or otherwise activates
the pointer in a manner that simulates such an action. The actuation
method of the mouse button depends upon the pointer device and the
environment configuration, e.g., it MAY depend on the screen
location or the delay between the press and release of the pointing
device button.
The click event should only be fired for the primary pointer
button (i.e., when button value is 0,
buttons value is 1). Secondary buttons
(like the middle or right button on a standard mouse) MUST NOT fire
click events. See auxclick for a corresponding event that
is associated with the non-primary buttons.
The click event MAY be preceded by the mousedown and
mouseup events on the same element, disregarding changes
between other node types (e.g., text nodes). Depending upon the
environment configuration, the click event MAY be dispatched
if one or more of the event types mouseover,
mousemove, and mouseout occur between the press and
release of the pointing device button. The click event MAY
also be followed by the dblclick event.
If a user mouses down on a text node child of a
<p> element which has been styled with a large
line-height, shifts the mouse slightly such that it is no longer
over an area containing text but is still within the containing
block of that <p> element (i.e., the pointer is
between lines of the same text block, but not over the text node per
se), then subsequently mouses up, this will likely still trigger a
click event (if it falls within the normal temporal
hysteresis for a click), since the user has stayed
within the scope of the same element. Note that user-agent-generated
mouse events are not dispatched on text nodes.
In addition to being associated with pointer devices, the
click event type MUST be dispatched as part of an element
activation.
For maximum accessibility, content authors are encouraged to use the
click event type when defining activation behavior for custom
controls, rather than other pointing-device event types such as
mousedown or mouseup, which are more device-specific.
Though the click event type has its origins in pointer
devices (e.g., a mouse), subsequent implementation enhancements have
extended it beyond that association, and it can be considered a
device-independent event type for element activation.
The default action of the click event type varies
based on the target of the event and the value of the
button or buttons attributes. Typical
default actions of the click event type are as follows:
- If the target has associated activation behavior, the default action MUST be to execute that activation behavior.
- If the target is focusable, the default action MUST be to give that element document focus.
| Type | dblclick |
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | None |
| Context (trusted events) |
|
A user agent MUST dispatch this event when the primary button
of a pointing device is clicked twice over an element. The
definition of a double click depends on the environment
configuration, except that the event target MUST be the same between
mousedown, mouseup, and dblclick. This event
type MUST be dispatched after the event type click if a click
and double click occur simultaneously, and after the event type
mouseup otherwise.
As with the click event, the dblclick event should
only be fired for the primary pointer button. Secondary buttons MUST NOT fire dblclick events.
click event type, the default action of
the dblclick event type varies based on the target of the event and the value of the button
or buttons attributes. The typical
default actions of the dblclick event type match those
of the click event type.
| Type | mousedown
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | Varies: Start a drag/drop operation; start a text selection; start a scroll/pan interaction (in combination with the middle mouse button, if supported) |
| Context (trusted events) |
|
Many implementations use the mousedown event to begin a
variety of contextually dependent default actions. These
default actions can be prevented if this event is canceled. Some of
these default actions could include: beginning a drag/drop
interaction with an image or link, starting text selection, etc.
Additionally, some implementations provide a mouse-driven panning
feature that is activated when the middle mouse button is pressed at
the time the mousedown event is dispatched.
| Type | mouseenter
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | No |
| Trusted Targets | Element |
| Cancelable | No |
| Composed | No |
| Default action | None |
| Context (trusted events) |
|
mouseover, but
differs in that it does not bubble, and MUST NOT be dispatched when
the pointer device moves from an element onto the boundaries of one
of its descendent elements.
There are similarities between this event type and the CSS
:hover pseudo-class [CSS2].
See also the mouseleave event type.
| Type | mouseleave
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | No |
| Trusted Targets | Element |
| Cancelable | No |
| Composed | No |
| Default action | None |
| Context (trusted events) |
|
mouseout,
but differs in that does not bubble, and that it MUST NOT be
dispatched until the pointing device has left the boundaries of the
element and the boundaries of all of its children.
There are similarities between this event type and the CSS
:hover pseudo-class [CSS2].
See also the mouseenter event type.
| Type | mousemove
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | None |
| Context (trusted events) |
|
mousemove events
SHOULD be fired for sustained pointer-device movement, rather than a
single event for each instance of mouse movement. Implementations
are encouraged to determine the optimal frequency rate to balance
responsiveness with performance.
In some implementation environments, such as a browser,
mousemove events can continue to fire if the user began a
drag operation (e.g., a mouse button is pressed) and the pointing
device has left the boundary of the user agent.
This event was formerly specified to be non-cancelable in DOM Level 2 Events, but was changed to reflect existing interoperability between user agents.
| Type | mouseout
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | None |
| Context (trusted events) |
|
mouseleave, but differs in that
does bubble, and that it MUST be dispatched when the pointer device
moves from an element onto the boundaries of one of its descendent elements.
See also the mouseover event type.
| Type | mouseover
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | None |
| Context (trusted events) |
|
mouseenter, but differs in
that it bubbles, and that it MUST be dispatched when the pointer device moves onto the
boundaries of an element whose ancestor element is the target for the same event listener instance.
See also the mouseout event type.
| Type | mouseup
|
|---|---|
| Interface | MouseEvent |
| Sync / Async | Sync |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Yes |
| Composed | Yes |
| Default action | None |
| Context (trusted events) |
|
In some implementation environments, such as a browser, a
mouseup event can be dispatched even if the pointing device
has left the boundary of the user agent, e.g., if the user began a
drag operation with a mouse button pressed.
WebIDLdictionary PointerEventInit : MouseEventInit {
long pointerId = 0;
double width = 1;
double height = 1;
float pressure = 0;
float tangentialPressure = 0;
long tiltX;
long tiltY;
long twist = 0;
double altitudeAngle;
double azimuthAngle;
DOMString pointerType = "";
boolean isPrimary = false;
long persistentDeviceId = 0;
sequence<PointerEvent> coalescedEvents = [];
sequence<PointerEvent> predictedEvents = [];
};
[Exposed=Window]
interface PointerEvent : MouseEvent {
constructor(DOMString type, optional PointerEventInit eventInitDict = {});
readonly attribute long pointerId;
readonly attribute double width;
readonly attribute double height;
readonly attribute float pressure;
readonly attribute float tangentialPressure;
readonly attribute long tiltX;
readonly attribute long tiltY;
readonly attribute long twist;
readonly attribute double altitudeAngle;
readonly attribute double azimuthAngle;
readonly attribute DOMString pointerType;
readonly attribute boolean isPrimary;
readonly attribute long persistentDeviceId;
[SecureContext] sequence<PointerEvent> getCoalescedEvents();
sequence<PointerEvent> getPredictedEvents();
};
pointerId-
A unique identifier for the pointer causing the event. user agents MAY reserve a generic
pointerIdvalue of0or1for the primary mouse pointer. ThepointerIdvalue of-1MUST be reserved and used to indicate events that were generated by something other than a pointing device. For any other pointers, user agents are free to implement different strategies and approaches in how they assign apointerIdvalue. However, all active pointers in the top-level browsing context (as defined by [HTML]) must be unique, and the identifier MUST NOT be influenced by any other top-level browsing context (i.e. one top-level browsing context cannot assume that thepointerIdof a pointer will be the same when the pointer moves outside of the browsing context and into another top-level browsing context).The user agent MAY recycle previously retired values for
pointerIdfrom previous active pointers, or it MAY always reuse the samepointerIdfor a particular pointing device (for instance, to uniquely identify particular pen/stylus inputs from a specific user in a multi-user collaborative application). However, in the latter case, to minimize the chance of fingerprinting and tracking across different pages or domains, thepointerIdMUST only be associated explicitly with that particular pointing device for the lifetime of the page / session, and a new randomizedpointerIdMUST be chosen the next time that particular pointing device is used again in a new session.NoteThe
pointerIdselection algorithm is implementation specific. Authors cannot assume values convey any particular meaning other than an identifier for the pointer that is unique from all other active pointers. As an example, user agents may simply assign a number, starting from0, to any active pointers, in the order that they become active — but these values are not guaranteed to be monotonically increasing. As the reuse of the samepointerIdfor a particular pointing device is left up to individual implementations, authors are strongly discouraged from relying on it, and to refer topersistentDeviceIdinstead. width-
The width (magnitude on the X axis), in CSS pixels (see [CSS21]), of the contact geometry of the pointer. This value MAY be updated on each event for a given pointer. For inputs that typically lack contact geometry (such as a traditional mouse), and in cases where the actual geometry of the input is not detected by the hardware, the user agent MUST return a default value of
1. height-
The height (magnitude on the Y axis), in CSS pixels (see [CSS21]), of the contact geometry of the pointer. This value MAY be updated on each event for a given pointer. For inputs that typically lack contact geometry (such as a traditional mouse), and in cases where the actual geometry of the input is not detected by the hardware, the user agent MUST return a default value of
1. pressure-
The normalized pressure of the pointer input in the range of
[0,1], where0and1represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware and platforms that do not support pressure, the value MUST be0.5when in the active buttons state and0otherwise. tangentialPressure-
The normalized tangential pressure (also known as barrel pressure), typically set by an additional control (e.g. a finger wheel on an airbrush stylus), of the pointer input in the range of
[-1,1], where0is the neutral position of the control. Note that some hardware may only support positive values in the range of[0,1]. For hardware and platforms that do not support tangential pressure, the value MUST be0.NoteDespite the property's name, in practice the hardware controls/sensors that generate the values for this property may not necessarily be pressure sensitive. As an example, in most cases the finger wheel on most airbrush/painting stylus implementations can be freely set, rather than requiring the user to apply a constant pressure on the wheel to prevent it from returning to the zero position. tiltX-
The plane angle (in degrees, in the range of
[-90,90]) between the Y-Z plane and the plane containing both the transducer (e.g. pen/stylus) axis and the Y axis. A positivetiltXis to the right, in the direction of increasing X values.tiltXcan be used along withtiltYto represent the tilt away from the normal of a transducer with the digitizer. For hardware and platforms that do not report tilt or angle, the value MUST be0.
Figure 3 Positive tiltX. tiltY-
The plane angle (in degrees, in the range of
[-90,90]) between the X-Z plane and the plane containing both the transducer (e.g. pen/stylus) axis and the X axis. A positivetiltYis towards the user, in the direction of increasing Y values.tiltYcan be used along withtiltXto represent the tilt away from the normal of a transducer with the digitizer. For hardware and platforms that do not report tilt or angle, the value MUST be0.
Figure 4 Positive tiltY. twist-
The clockwise rotation (in degrees, in the range of
[0,359]) of a transducer (e.g. pen/stylus) around its own major axis. For hardware and platforms that do not report twist, the value MUST be0. altitudeAngle-
The altitude (in radians) of the transducer (e.g. pen/stylus), in the range
[0,π/2]— where0is parallel to the surface (X-Y plane), andπ/2is perpendicular to the surface. For hardware and platforms that do not report tilt or angle, the value MUST beπ/2.NoteThe default value defined here foraltitudeAngleisπ/2, which positions the transducer as being perpendicular to the surface. This differs from the Touch Events - Level 2 specification's definition for thealtitudeAngleproperty, which has a default value of0.
Figure 5 Example altitudeAngleofπ/4(45 degrees from the X-Y plane). azimuthAngle-
The azimuth angle (in radians) of the transducer (e.g. pen/stylus), in the range
[0, 2π]— where0represents a transducer whose cap is pointing in the direction of increasing X values (point to "3 o'clock" if looking straight down) on the X-Y plane, and the values progressively increase when going clockwise (π/2at "6 o'clock",πat "9 o'clock",3π/2at "12 o'clock"). When the transducer is perfectly perpendicular to the surface (altitudeAngleofπ/2), the value MUST be0. For hardware and platforms that do not report tilt or angle, the value MUST be0.
Figure 6 Example azimuthAngleofπ/6("4 o'clock"). pointerType-
Indicates the device type that caused the event (such as mouse, pen, touch). If the user agent is to fire a pointer event for a mouse, pen/stylus, or touch input device, then the value of
pointerTypeMUST be according to the following table:Pointer Device Type pointerTypeValueMouse mousePen / stylus penTouch contact touchIf the device type cannot be detected by the user agent, then the value MUST be an empty string. If the user agent supports pointer device types other than those listed above, the value of
pointerTypeSHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types.NoteSee Example 2 for a basic demonstration of how thepointerTypecan be used. Also note that developers should include some form of default handling to cover user agents that may have implemented their own custompointerTypevalues and for situations wherepointerTypeis simply an empty string. isPrimary-
Indicates if the pointer represents the primary pointer of this pointer type.
persistentDeviceId-
A unique identifier for the pointing device. If the hardware supports multiple pointers, pointer events generated from pointing devices MUST only get a
persistentDeviceIdif those pointers are uniquely identifiable over the session. If the pointer is uniquely identifiable, the assignedpersistentDeviceIdto that pointing device will remain constant for the remainder of the session. ThepersistentDeviceIdvalue of0MUST be reserved and used to indicate events whose generating device could not be identified. Like pointerId, to minimize the chance of fingerprinting and tracking across different pages or domains, thepersistentDeviceIdMUST only be associated explicitly with that particular pointing device for the lifetime of the page / session, and a new randomizedpersistentDeviceIdMUST be chosen the next time that particular pointing device is used again in a new session.NoteDue to digitizer and pointing device hardware constraints, apersistentDeviceIdis not guaranteed to be available for all pointer events from a pointing device. For example, the device may not report its hardware id to the digitizer in time forpointerdownto have apersistentDeviceId. In such a case, thepersistentDeviceIdmay initially be0and change to a valid value. getCoalescedEvents()-
A method that returns the list of coalesced events.
getPredictedEvents()-
A method that returns the list of predicted events.
The PointerEventInit dictionary is used by the PointerEvent interface's constructor to provide a mechanism by which to construct untrusted (synthetic) pointer events. It inherits from the MouseEventInit dictionary defined in [UIEVENTS]. See the examples for sample code demonstrating how to fire an untrusted pointer event.
The event constructing steps for PointerEvent
clones PointerEventInit's coalescedEvents to coalesced events list and
clones PointerEventInit's predictedEvents to predicted events list.
PointerEvent interface inherits from MouseEvent, defined in UI Events.
Also note the proposed extension in CSSOM View Module, which changes the various coordinate properties from long
to double to allow for fractional coordinates. For user agents that already implement this proposed extension for
PointerEvent, but not for regular MouseEvent, there are additional requirements when it comes to
the click, auxclick, and contextmenu events.In a multi-pointer (e.g. multi-touch) scenario, the isPrimary property is used to identify a master pointer amongst the set of active pointers for each pointer type.
- At any given time, there can only ever be at most one primary pointer for each pointer type.
- The first pointer to become active for a particular pointer type (e.g. the first finger to touch the screen in a multi-touch interaction) becomes the primary pointer for that pointer type.
- Only a primary pointer will produce compatibility mouse events. In the case where there are multiple primary pointers, these pointers will all produce compatibility mouse events.
pointerType) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.false for isPrimary.To fire a pointer event named e means to fire an event named e using PointerEvent whose attributes are set as defined in PointerEvent Interface and Attributes and Default Actions.
If the event is not a gotpointercapture, lostpointercapture, click, auxclick or contextmenu event, run the process pending pointer capture steps for this PointerEvent.
Determine the target at which the event is fired as follows:
- If the pointer capture target override has been set for the pointer, set the target to pointer capture target override object.
- Otherwise, set the target to the object returned by hit test.
Let targetDocument be target's node document [DOM].
If the event is pointerdown, pointermove, or pointerup, set active document for the event's pointerId to targetDocument.
If the event is pointerdown, the associated device is a direct manipulation device, and the target is an Element,
then set pointer capture for this pointerId to the target element as described in implicit pointer capture.
Before firing this event, the user agent SHOULD treat the target as if the pointing device has moved over it from the previousTarget for the purpose of ensuring event ordering [UIEVENTS]. If the needsOverEvent flag is set, a pointerover event is needed even if the target element is the same.
Fire the event to the determined target.
Save the determined target as the previousTarget for the given pointer,
and reset the needsOverEvent flag to false.
If the previousTarget at any point will no longer be connected [DOM],
update the previousTarget to the nearest still connected [DOM] parent
following the event path corresponding to dispatching events to the previousTarget,
and set the needsOverEvent flag to true.
The bubbles and cancelable properties and the default actions for the event types defined in this specification appear in the following table. Details of each of these event types are provided in Pointer Event types.
| Event Type | Bubbles | Cancelable | Default Action |
|---|---|---|---|
pointerover |
Yes | Yes | None |
pointerenter |
No | No | None |
pointerdown |
Yes | Yes | Varies: when the pointer is primary, all default actions of the mousedown event
Canceling this event also prevents subsequent firing of compatibility mouse events. |
pointermove |
Yes | Yes | Varies: when the pointer is primary, all default actions of mousemove |
pointerrawupdate |
Yes | No | None |
pointerup |
Yes | Yes | Varies: when the pointer is primary, all default actions of mouseup |
pointercancel |
Yes | No | None |
pointerout |
Yes | Yes | None |
pointerleave |
No | No | None |
gotpointercapture |
Yes | No | None |
lostpointercapture |
Yes | No | None |
Viewport manipulations (panning and zooming) — generally, as a result of a direct manipulation interaction — are intentionally NOT a default action of pointer events, meaning that these behaviors (e.g. panning a page as a result of moving a finger on a touchscreen) cannot be suppressed by canceling a pointer event. Authors must instead use touch-action to explicitly declare the direct manipulation behavior for a region of the document. Removing this dependency on the cancelation of events facilitates performance optimizations by the user agent.
For pointerenter and pointerleave events, the composed [DOM] attribute SHOULD be false; for all other pointer events in the table above, the attribute SHOULD be true.
For all pointer events in the table above, the detail [UIEVENTS] attribute SHOULD be 0.
fromElement and toElement in MouseEvents to support legacy content. We encourage those user agents to set the values of those (inherited) attributes in PointerEvents to null to transition authors to the use of standardized alternates (target and relatedTarget).Similar to MouseEvent relatedTarget, the relatedTarget should be initialized to the element whose bounds the pointer just left (in the case of a pointerover or pointerenter event) or the element whose bounds the pointer is entering (in the case of a pointerout or pointerleave). For other pointer events, this value will default to null. Note that when an element receives the pointer capture all the following events for that pointer are considered to be inside the boundary of the capturing element.
For gotpointercapture and lostpointercapture events, all the attributes except the ones defined in the table above should be the same as the Pointer Event that caused the user agent to run the process pending pointer capture steps and fire the gotpointercapture and lostpointercapture events.
The user agent MUST run the following steps when implicitly releasing pointer capture as well as when firing Pointer Events that are not gotpointercapture or lostpointercapture.
- If the pointer capture target override for this pointer is set and is not equal to the pending pointer capture target override, then fire a pointer event named
lostpointercaptureat the pointer capture target override node. - If the pending pointer capture target override for this pointer is set and is not equal to the pointer capture target override, then fire a pointer event named
gotpointercaptureat the pending pointer capture target override. - Set the pointer capture target override to the pending pointer capture target override, if set. Otherwise, clear the pointer capture target override.
As defined in the section for click, auxclick, and contextmenu events, even after the lostpointercapture event has been dispatched,
the corresponding click, auxclick or contextmenu event, if any, would still be dispatched to the capturing target.
The user agent MUST suppress a pointer event stream when it detects that the web page is unlikely to continue to receive pointer events with a specific pointerId. Any of the following scenarios satisfy this condition (there MAY be additional scenarios):
- The user agent has opened a modal dialog or menu.
- A pointer input device is physically disconnected, or a hoverable pointer input device (e.g. a hoverable pen/stylus) has left the hover range detectable by the digitizer.
- The pointer is subsequently used by the user agent to manipulate the page viewport (e.g. panning or zooming). See the section on
touch-actionCSS property for details.NoteUser agents can trigger panning or zooming through multiple pointer types (such as touch and pen), and therefore the start of a pan or zoom action may result in the suppression of various pointers, including pointers with different pointer types. - As part of the drag operation initiation algorithm as defined in the drag and drop processing model [HTML], for the pointer that caused the drag operation.
Other scenarios in which the user agent MAY suppress a pointer event stream include:
- A device's screen orientation is changed while a pointer is active.
- The user attempts to interact using more simultaneous pointer inputs than the device supports.
- The user agent interprets the input as accidental (for example, the hardware supports palm rejection).
Methods for detecting any of these scenarios are out of scope for this specification.
The user agent MUST run the following steps to suppress a pointer event stream:
- Fire a
pointercancelevent. - Fire a
pointeroutevent. - Fire a
pointerleaveevent. - Implicitly release the pointer capture if the pointer is currently captured.
A pointing device that moved relative to the screen surface or underwent some change in any of its properties fires various events as defined in Pointer Event types. For a stationary pointing device (that neither moved relative to the screen surface nor underwent any change in any properties), the user agent MUST fire certain boundary events after a layout change that affected the hit test target for the pointer, see pointerover, pointerenter, pointerout and pointerleave for details. The user agent MAY delay the firing of these boundary events because of performance reasons (e.g. to avoid too many hit-tests or layout changes caused by boundary event listeners).
pointermove event.Pointer Events include two complementary sets of attributes to express the orientation of a transducer relative to the X-Y plane: tiltX / tiltY (introduced in the original Pointer Events specification), and azimuthAngle / altitudeAngle (adopted from the Touch Events - Level 2 specification).
Depending on the specific hardware and platform, user agents will likely only receive one set of values for the transducer orientation relative to the screen plane — either tiltX / tiltY or altitudeAngle / azimuthAngle. User agents MUST use the following algorithm for converting these values.
When the user agent calculates tiltX / tiltY from azimuthAngle / altitudeAngle it SHOULD round the final integer values using Math.round [ECMASCRIPT] rules.
/* Converting between tiltX/tiltY and altitudeAngle/azimuthAngle */
function spherical2tilt(altitudeAngle, azimuthAngle) {
const radToDeg = 180/Math.PI;
let tiltXrad = 0;
let tiltYrad = 0;
if (altitudeAngle == 0) {
// the pen is in the X-Y plane
if (azimuthAngle == 0 || azimuthAngle == 2*Math.PI) {
// pen is on positive X axis
tiltXrad = Math.PI/2;
}
if (azimuthAngle == Math.PI/2) {
// pen is on positive Y axis
tiltYrad = Math.PI/2;
}
if (azimuthAngle == Math.PI) {
// pen is on negative X axis
tiltXrad = -Math.PI/2;
}
if (azimuthAngle == 3*Math.PI/2) {
// pen is on negative Y axis
tiltYrad = -Math.PI/2;
}
if (azimuthAngle>0 && azimuthAngle<Math.PI/2) {
tiltXrad = Math.PI/2;
tiltYrad = Math.PI/2;
}
if (azimuthAngle>Math.PI/2 && azimuthAngle<Math.PI) {
tiltXrad = -Math.PI/2;
tiltYrad = Math.PI/2;
}
if (azimuthAngle>Math.PI && azimuthAngle<3*Math.PI/2) {
tiltXrad = -Math.PI/2;
tiltYrad = -Math.PI/2;
}
if (azimuthAngle>3*Math.PI/2 && azimuthAngle<2*Math.PI) {
tiltXrad = Math.PI/2;
tiltYrad = -Math.PI/2;
}
}
if (altitudeAngle != 0) {
const tanAlt = Math.tan(altitudeAngle);
tiltXrad = Math.atan(Math.cos(azimuthAngle) / tanAlt);
tiltYrad = Math.atan(Math.sin(azimuthAngle) / tanAlt);
}
return {"tiltX":tiltXrad*radToDeg, "tiltY":tiltYrad*radToDeg};
}
function tilt2spherical(tiltX, tiltY) {
const tiltXrad = tiltX * Math.PI/180;
const tiltYrad = tiltY * Math.PI/180;
// calculate azimuth angle
let azimuthAngle = 0;
if (tiltX == 0) {
if (tiltY > 0) {
azimuthAngle = Math.PI/2;
}
else if (tiltY < 0) {
azimuthAngle = 3*Math.PI/2;
}
} else if (tiltY == 0) {
if (tiltX < 0) {
azimuthAngle = Math.PI;
}
} else if (Math.abs(tiltX) == 90 || Math.abs(tiltY) == 90) {
// not enough information to calculate azimuth
azimuthAngle = 0;
} else {
// Non-boundary case: neither tiltX nor tiltY is equal to 0 or +-90
const tanX = Math.tan(tiltXrad);
const tanY = Math.tan(tiltYrad);
azimuthAngle = Math.atan2(tanY, tanX);
if (azimuthAngle < 0) {
azimuthAngle += 2*Math.PI;
}
}
// calculate altitude angle
let altitudeAngle = 0;
if (Math.abs(tiltX) == 90 || Math.abs(tiltY) == 90) {
altitudeAngle = 0
} else if (tiltX == 0) {
altitudeAngle = Math.PI/2 - Math.abs(tiltYrad);
} else if (tiltY == 0) {
altitudeAngle = Math.PI/2 - Math.abs(tiltXrad);
} else {
// Non-boundary case: neither tiltX nor tiltY is equal to 0 or +-90
altitudeAngle = Math.atan(1.0/Math.sqrt(Math.pow(Math.tan(tiltXrad),2) + Math.pow(Math.tan(tiltYrad),2)));
}
return {"altitudeAngle":altitudeAngle, "azimuthAngle":azimuthAngle};
}
5.2.1 initialize a PointerEvent
To initialize a PointerEvent with event, eventType and eventTarget, bubbles, and cancelable, run the following steps:
- Initialize a MouseEvent with event, eventType and eventTarget, bubbles and cancelable
- Initialize all other attributes to default
PointerEventvalues.
5.2.2 create a PointerEvent
To create a PointerEvent with eventType and eventTarget, bubbles, and cancelable, run the following steps:
- Let event be the result of
creating an event using
PointerEvent - Initialize a PointerEvent with event, eventType and eventTarget, bubbles and cancelable
- Return event
- Let eventType be a
DOMStringcontaining the event type - Let mouseevent be the corresponding
MouseEvent - Let event be the result of
creating an event using
PointerEvent - Let target be the mouseevent.
target - Initialize a PointerEvent with event, eventType and target
- Copy
MouseEventattributes from mouseevent into event - Return event
- Let mouseout be the corresponding mouseout
MouseEvent - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEvent - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEvent - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEvent - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEventEditor's noteCan this send pointermove and pointerrawupdate? Or do we need 2 methods?
Editor's noteWhat is needed to properly define how pointermove events are coalesced?
- Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEventNoteUnlike
mousedownevents,pointerdownevents are not nested when multiple buttons are pressed. TheMouseEventis passed so that the fields can be copied into the PointerEvent. - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEvent - Let target be the mouseout.
target - dispatch pointerout at target
- Let mouseout be the corresponding mouseout
MouseEventNoteUnlike
mouseupevents,pointerupevents are not nested when multiple buttons are pressed. TheMouseEventis passed so that the fields can be copied into the PointerEvent. - Let pointerout be the result of creating PointerEvent from MouseEvent with "pointerout" and mouseout
- Set pointerevent attributes
Editor's note
TODO.
- Let target be the mouseout.
target - dispatch pointerout at target
Below are the event types defined in this specification.
In the case of the primary pointer, these events (with the exception of gotpointercapture and lostpointercapture) may also fire compatibility mouse events.
The user agent MUST fire a pointer event named pointerover when any of the following occurs:
- The step to determine the target of a pointer detects that the pointer has moved into an element.
- A layout change causes the hit test boundaries of an element to move underneath an uncaptured pointer of a stationary pointing device.
- Before the user agent fires a
pointerdownevent for a device that does not support hover (seepointerdown).
The user agent MUST fire a pointer event named pointerenter when any of the following occurs:
- The step to determine the target of a pointer detects that the pointer has moved into an element or one of its descendants.
- A layout change causes the hit test boundaries of an element or one of its descendants to move underneath an uncaptured pointer of a stationary pointing device.
- Before the user agent fires a
pointerdownevent for a device that does not support hover (seepointerdown).
pointerover but with two differences: pointerenter does not bubble, and its dispatch considers the hit test boundaries of even descendant elements.mouseenter event described in [UIEVENTS], and the CSS :hover pseudo-class described in [CSS21]. See also the pointerleave event.The user agent MUST fire a pointer event named pointerdown when a pointer enters the active buttons state. For mouse, this is when the device transitions from no buttons depressed to at least one button depressed. For touch, this is when physical contact is made with the digitizer. For pen, this is when the pen either makes physical contact with the digitizer without any button depressed, or transitions from no buttons depressed to at least one button depressed while hovering.
pointerdown and pointerup are not fired for all of the same circumstances as mousedown and mouseup. See chorded buttons for more information.For input devices that do not support hover, the user agent MUST also fire a pointer event named pointerover followed by a pointer event named pointerenter prior to dispatching the pointerdown event.
pointerdown event (if the isPrimary property is true). This sets the PREVENT MOUSE EVENT flag on the pointer. Note, however, that this does not prevent the mouseover, mouseenter, mouseout, or mouseleave events from firing.The user agent MUST fire a pointer event named pointermove when a pointer changes any properties that don't fire
pointerdown or pointerup events. This includes any changes to coordinates, pressure, tangential pressure,
tilt, twist, contact geometry (width and height) or chorded buttons.
User agents MAY delay dispatch of the pointermove event (for instance, for performance reasons).
The coalesced events information will be exposed via thegetCoalescedEvents method for the single dispatched pointermove event.
The final coordinates of such events should be used for finding the target of the event.
The user agent MUST fire a pointer event
named pointerrawupdate, and only do so within a secure context, when a pointer changes any properties that don't fire
pointerdown or pointerup events. See pointermove event for a list of such properties.
In contrast with pointermove, user agents SHOULD dispatch pointerrawupdate events as soon as possible
and as frequently as the JavaScript can handle the events.
The target of pointerrawupdate events might be different from the pointermove events
due to the fact that pointermove events might get delayed or coalesced, and the final position of the event
which is used for finding the target could be different from its coalesced events.
Note that if there is already another pointerrawupdate with the same pointerId that hasn't been dispatched
in the event loop, the
user agent MAY coalesce the new pointerrawupdate with that event instead of creating a new task.
This may cause pointerrawupdate to have coalesced events, and
they will all be delivered as coalesced events of one pointerrawupdate event as soon as
the event is processed in the event loop.
SeegetCoalescedEvents for more information.
In terms of ordering of pointerrawupdate and pointermove,
if the user agent received an update from the platform that causes both pointerrawupdate and pointermove events,
then the user agent MUST dispatch the pointerrawupdate event before the corresponding pointermove.
Other than the target, the concatenation of coalesced events lists of all dispatched pointerrawupdate events
since the last pointermove event is the same as the coalesced events of the next pointermove event in terms of the other event attributes.
The attributes of pointerrawupdate are mostly the same as pointermove, with the exception of
cancelable which MUST be false for pointerrawupdate.
User agents SHOULD not fire compatibility mouse events for pointerrawupdate.
pointerrawupdate event might negatively impact the performance of the web page, depending on the implementation of the user agent.
For most use cases the other pointerevent types should suffice.
A pointerrawupdate listener should only be added if JavaScript needs high frequency events and can handle them just as fast.
In these cases, there is probably no need to listen to other types of pointer events.The user agent MUST fire a pointer event named pointerup when a pointer leaves the active buttons state. For mouse, this is when the device transitions from at least one button depressed to no buttons depressed. For touch, this is when physical contact is removed from the digitizer. For pen, this is when the pen is removed from the physical contact with the digitizer while no button is depressed, or transitions from at least one button depressed to no buttons depressed while hovering.
For input devices that do not support hover, the user agent MUST also fire a pointer event named pointerout followed by a pointer event named pointerleave after dispatching the pointerup event.
All pointerup events have a pressure value of 0.
The user agent MUST also implicitly release the pointer capture if the pointer is currently captured.
pointerdown and pointerup are not fired for all of the same circumstances as mousedown and mouseup. See chorded buttons for more information.The user agent MUST fire a pointer event named pointercancel when it detects a scenario to suppress a pointer event stream.
The values of the following properties of the pointercancel event MUST match the values of the last dispatched pointer event with the same pointerId: width, height, pressure, tangentialPressure, tiltX, tiltY, twist, altitudeAngle, azimuthAngle, pointerType, isPrimary, and the coordinates inherited from [UIEVENTS]. The coalescedEvents and predictedEvents lists in the pointercancel event MUST be empty, and the event's cancelable attribute MUST be false.
The user agent MUST fire a pointer event named pointerout when any of the following occurs:
- The step to determine the target of a pointer detects that the pointer has moved out of an element.
- A layout change causes the hit test boundaries of an element to move away from underneath an uncaptured pointer of a stationary pointing device.
- After the user agent fires a
pointerupevent for a device that does not support hover (seepointerup). - The user agent has detected a scenario to suppress a pointer event stream.
The user agent MUST fire a pointer event named pointerleave when any of the following occurs:
- The step to determine the target of a pointer detects that the pointer has moved out of an element and all of its descendants.
- A layout change causes the hit test boundaries of an element and all of its descendants to move away from underneath an uncaptured pointer of a stationary pointing device.
- After the user agent fires the
pointerupevent for a device that does not support hover (seepointerup). - The user agent has detected a scenario to suppress a pointer event stream.
pointerout but with two differences: pointerleave does not bubble, and its dispatch considers the hit test boundaries of even descendant elements.mouseleave event described in [UIEVENTS], and the CSS :hover pseudo-class described in [CSS21]. See also the pointerenter event.The user agent MUST fire a pointer event named gotpointercapture when an element receives pointer capture. This event is fired at the element that is receiving pointer capture. Subsequent events for that pointer will be fired at this element. See the setting pointer capture and process pending pointer capture sections.
The user agent MUST fire a pointer event named lostpointercapture after pointer capture is released for a pointer. This event MUST be fired prior to any subsequent events for the pointer after capture was released. This event is fired at the element from which pointer capture was removed. All subsequent events for the pointer except click, auxclick, and contextmenu events follow normal hit testing mechanisms (out of scope for this specification) for determining the event target. See the releasing pointer capture, implicit release of pointer capture, and process pending pointer capture sections.
The user's environment might be configured to associate vertical scrolling with rotation along the y-axis, horizontal scrolling with rotation along the x-axis, and zooming with rotation along the z-axis.
The deltaX, deltaY, and deltaZ attributes ofWheelEvent 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.
A user's environment settings can be customized to interpret actual rotation/movement
of a wheel device in different ways.
One movement of a common dented
mouse wheel can produce a measurement of 162 pixels
(162 is just an example value, actual values can depend on the current screen
dimensions of the user-agent).
But a user can change their default environment settings to speed-up their mouse wheel,
increasing this number.
Furthermore, some mouse wheel software can support acceleration (the faster the wheel
is rotated/moved, the greater the delta of each measurement) or even sub-pixel rotation
measurements.
Because of this, authors can not assume a given rotation amount in one user agent will
produce the same delta value in all user agents.
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.
Individual user agents can (depending on their environment and hardware configuration) interpret the same physical user interaction on the wheel differently. For example, a vertical swipe on the edge of a trackpad from top to bottom can be interpreted as a wheel action intended to either scroll the page down or to pan the page up (i.e., resulting in either a positive or negative deltaY value respectively).
If a series of wheel events targetted in a scrollable element start above a child element, later events for the same user gesture may occur over the child element.
WheelEvent interface provides specific contextual information
associated with wheel events.
To create an instance of the WheelEvent interface, use the WheelEvent constructor,
passing an optional WheelEventInit dictionary.
WebIDL[Exposed=Window]
interface WheelEvent : MouseEvent {
constructor(DOMString type, optional WheelEventInit eventInitDict = {});
// 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;
};
DOM_DELTA_PIXEL- The units of measurement for the delta MUST be pixels. This is the most typical case in most operating system and implementation configurations.
DOM_DELTA_LINE- The units of measurement for the delta MUST be individual lines of text. This is the case for many form controls.
DOM_DELTA_PAGE- The units of measurement for the delta MUST be pages, either defined as a single screen or as a demarcated page.
deltaX-
In user agents where the default action of the
wheelevent is to scroll, the value MUST be the measurement along the x-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the x-axis. The un-initialized value of this attribute MUST be0.0. deltaY-
In user agents where the default action of the
wheelevent is to scroll, the value MUST be the measurement along the y-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the y-axis. The un-initialized value of this attribute MUST be0.0. deltaZ-
In user agents where the default action of the
wheelevent is to scroll, the value MUST be the measurement along the z-axis (in pixels, lines, or pages) to be scrolled in the case where the event is not cancelled. Otherwise, this is an implementation-specific measurement (in pixels, lines, or pages) of the movement of a wheel device around the z-axis. The un-initialized value of this attribute MUST be0.0. deltaMode-
The
deltaModeattribute contains an indication of the units of measurement for the delta values. The default value isDOM_DELTA_PIXEL(pixels). This attribute MUST be set to one of the DOM_DELTA constants to indicate the units of measurement for the delta values. The precise measurement is specific to device, operating system, and application configurations. The un-initialized value of this attribute MUST be0.
WebIDLdictionary WheelEventInit : MouseEventInit {
double deltaX = 0.0;
double deltaY = 0.0;
double deltaZ = 0.0;
unsigned long deltaMode = 0;
};
deltaX- See
deltaZattribute. deltaY- See
deltaZattribute. deltaZ-
Initializes the
deltaZattribute of theWheelEventobject. Relative positive values for this attribute (as well as thedeltaXanddeltaYattributes) are given by a right-hand coordinate system where the 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. Negative relative values are in the respective opposite directions. deltaMode-
Initializes the
deltaModeattribute on theWheelEventobject to the enumerated values 0, 1, or 2, which represent the amount of pixels scrolled (DOM_DELTA_PIXEL), lines scrolled (DOM_DELTA_LINE), or pages scrolled (DOM_DELTA_PAGE) if the rotation of the wheel would have resulted in scrolling.
| Type | wheel |
|---|---|
| Interface | WheelEvent |
| Sync / Async | Async |
| Bubbles | Yes |
| Trusted Targets | Element |
| Cancelable | Varies |
| Composed | Yes |
| Default action | Scroll (or zoom) the document |
| Context (trusted events) |
|
wheel event with multiple non-zero axes or as separate
wheel events for each non-zero axis.
The typical default action of the wheel event type is
to scroll (or in some cases, zoom) the document by the indicated
amount. If this event is canceled, the implementation MUST NOT
scroll or zoom the document (or perform whatever other
implementation-specific default action is associated with this event
type).
In some user agents, or with some input devices, the speed that the wheel has been turned can affect the delta values, with a faster speed producing a higher delta value.
Calling preventDefault on a wheel event can prevent
or otherwise interrupt scrolling. For maximum scroll performance, a
user agent may not wait for each wheel event associated with the scroll
to be processed to see if it will be canceled. In such cases the user
agent should generate wheel events whose
cancelable property is false, indicating that
preventDefault cannot be used to prevent or interrupt
scrolling. Otherwise cancelable will be true.
In particular, a user agent should generate only uncancelable
wheel events when it
observes
that there are no non-passive listeners for the event.
The following section describes extensions to the existing Element interface to facilitate the setting and releasing of pointer capture.
WebIDLpartial interface Element {
undefined setPointerCapture (long pointerId);
undefined releasePointerCapture (long pointerId);
boolean hasPointerCapture (long pointerId);
};
setPointerCapture()-
Set pointer capture for the pointer identified by the argument
pointerIdto the element on which this method is invoked. For subsequent events of the pointer, the capturing target will substitute the normal hit testing result as if the pointer is always over the capturing target, and they MUST always be targeted at this element until capture is released. The pointer MUST be in its active buttons state for this method to be effective, otherwise it fails silently. When the provided method's argument does not match any of the active pointers, throw a "NotFoundError"DOMException. releasePointerCapture()-
Release pointer capture for the pointer identified by the argument
pointerIdfrom the element on which this method is invoked. Subsequent events for the pointer follow normal hit testing mechanisms (out of scope for this specification) for determining the event target. When the provided method's argument does not match any of the active pointers, throw a "NotFoundError"DOMException. hasPointerCapture-
Indicates whether the element on which this method is invoked has pointer capture for the pointer identified by the argument
pointerId. In particular, returnstrueif the pending pointer capture target override forpointerIdis set to the element on which this method is invoked, andfalseotherwise.NoteThis method will return true immediately after a call tosetPointerCapture(), even though that element will not yet have received agotpointercaptureevent. As a result it can be useful for detecting implicit pointer capture from inside of apointerdownevent listener.
The following section describes extensions to the existing GlobalEventHandlers mixin to facilitate the event handler registration.
WebIDLpartial interface mixin GlobalEventHandlers {
attribute EventHandler onpointerover;
attribute EventHandler onpointerenter;
attribute EventHandler onpointerdown;
attribute EventHandler onpointermove;
[SecureContext] attribute EventHandler onpointerrawupdate;
attribute EventHandler onpointerup;
attribute EventHandler onpointercancel;
attribute EventHandler onpointerout;
attribute EventHandler onpointerleave;
attribute EventHandler ongotpointercapture;
attribute EventHandler onlostpointercapture;
};
onpointerover-
The event handler IDL attribute for the
pointeroverevent type. onpointerenter-
The event handler IDL attribute for the
pointerenterevent type. onpointerdown-
The event handler IDL attribute for the
pointerdownevent type. onpointermove-
The event handler IDL attribute for the
pointermoveevent type. onpointerrawupdate-
The event handler IDL attribute for the
pointerrawupdateevent type. onpointerup-
The event handler IDL attribute for the
pointerupevent type. onpointercancel-
The event handler IDL attribute for the
pointercancelevent type. onpointerout-
The event handler IDL attribute for the
pointeroutevent type. onpointerleave-
The event handler IDL attribute for the
pointerleaveevent type. ongotpointercapture-
The event handler IDL attribute for the
gotpointercaptureevent type. onlostpointercapture-
The event handler IDL attribute for the
lostpointercaptureevent type.
As noted in Attributes and Default Actions, viewport manipulations (panning and zooming) cannot be suppressed by canceling a pointer event. Instead, authors must declaratively define which of these behaviors they want to allow, and which they want to suppress, using the touch-action CSS property.
touch-action CSS property defined in this specification appears to refer only to touch inputs, it does in fact apply to all forms of pointer inputs that allow direct manipulation for panning and zooming.| Name: | touch-action |
|---|---|
| Value: | auto | none | [ [ pan-x | pan-left | pan-right ] || [ pan-y | pan-up | pan-down ] ] | manipulation |
| Initial: | auto |
| Applies to: | all elements except: non-replaced inline elements, table rows, row groups, table columns, and column groups |
| Inherited: | no |
| Percentages: | N/A |
| Media: | visual |
| Computed value: | same as specified value |
| Canonical order: | per grammar |
| Animation type: | not animatable |
The touch-action CSS property determines whether direct manipulation interactions (which are not limited to touch, despite the property's name) MAY trigger the user agent's panning and zooming behavior. See the section on touch-action values.
Right before starting to pan or zoom, the user agent MUST suppress a pointer event stream if all of the following conditions are true:
- The user agent has determined (via methods out of scope for this specification) that a direct manipulation interaction is to be consumed for panning or zooming,
- a
pointerdownevent has been sent for the pointer, and - a
pointeruporpointercancelevent (following the above mentionedpointerdown) has not yet been sent for the pointer.
touch-action does not apply/cascade through to embedded browsing contexts. For instance, even applying touch-action to an <iframe> won't have any effect on the behavior of direct manipulation interactions for panning and zooming within the <iframe> itself.When a user interacts with an element using a direct manipulation pointer (such as touch or stylus on a touchscreen), the effect of that input is determined by the value of the touch-action property, and the default direct manipulation behaviors of the element and its ancestors, as follows:
- A direct manipulation interaction for panning and zooming conforms to an element's
touch-actionif the behavior is allowed in the coordinate space of the element. Note that if CSS transforms have been applied, the element's coordinate space may differ from the screen coordinate in a way that affects the conformity here; for example, the X axis of an element rotated by 90 degrees with respect to the screen will be parallel to the Y-axis of the screen coordinate. - A direct manipulation interaction for panning is supported if it conforms to the
touch-actionproperty of each element between the hit tested element and its nearest inclusive ancestor that is a scroll container (as defined in [CSS-OVERFLOW-3]). - A direct manipulation interaction for zooming is supported if it conforms to the
touch-actionproperty of each element between the hit tested element and thedocumentelement of the top-level browsing context (as defined in [HTML]). - Once panning or zooming has been started, and the user agent has already determined whether or not the gesture should be handled as a user agent direct manipulation behavior, any changes to the relevant
touch-actionvalue will be ignored for the duration of the action. For instance, programmatically changing thetouch-actionvalue for an element fromautotononeas part of apointerdownhandler script will not result in the user agent aborting or suppressing any of the pan or zoom behavior for that input for as long as that pointer is active. - Similarly, in the case of the various
touch-actionvalues ofpan-*, once the user agent has determined whether to handle a gesture directly or not at the start of the gesture, a subsequent change in the direction of the same gesture SHOULD be ignored by the user agent for as long as that pointer is active. For instance, if an element has been set totouch-action: pan-y(meaning that only vertical panning is handled by the user agent), and a touch gesture starts off horizontally, no vertical panning should occur if the user changes the direction of their gesture to be vertical while their finger is still touching the screen.
touch-action values of multiple concurrent pointers is out of scope for this specification.The touch-action property covers direct manipulation behaviors related to viewport panning and zooming. Any additional user agent behaviors, such as text selection/highlighting, or activating links and form controls, MUST NOT be affected by this CSS property.
auto or none values, are out of scope for this specification.- auto
- The user agent MAY consider any permitted direct manipulation behaviors related to panning and zooming of the viewport that begin on the element.
- none
- Direct manipulation interactions that begin on the element MUST NOT trigger behaviors related to viewport panning and zooming.
- pan-x
pan-left
pan-right
pan-y
pan-up
pan-down - The user agent MAY consider direct manipulation interactions that begin on the element only for the purposes of panning that starts in any of the directions specified by all of the listed values. Once panning has started, the direction may be reversed by the user even if panning that starts in the reversed direction is disallowed. In contrast, when panning is restricted to a single axis (for instance, with
pan-xorpan-y), the axis cannot be changed during panning. - manipulation
- The user agent MAY consider direct manipulation interactions that begin on the element only for the purposes of panning and continuous zooming (such as pinch-zoom), but MUST NOT trigger other related behaviors that rely on multiple activations that must happen within a set period of time (such as double-tap to zoom, or double-tap and hold for single-finger zoom).
touch-action values common in implementations are defined in [COMPAT].touch-action property only applies to elements that support both the CSS width and height properties (see [CSS21]). This restriction is designed to facilitate user agent optimizations for low-latency direct manipulation panning and zooming. For elements not supported by default, such as <span> which is a non-replaced inline element, authors can set the display CSS property to a value, such as block, that supports width and height. Future specifications could extend this API to all elements.The direction-specific pan values are useful for customizing some overscroll behaviors.
For example, to implement a simple pull-to-refresh effect the document's touch-action can be set to pan-x pan-down whenever the scroll position is 0 and pan-x pan-y otherwise.
This allows pointer event handlers to define the behavior for upward panning/scrolling that start from the top of the document.
The direction-specific pan values can also be used for composing a component that implements custom panning with pointer event handling within an element that scrolls natively (or vice-versa).
For example, an image carousel may use pan-y to ensure it receives pointer events for any horizontal pan operations without interfering with vertical panning of the document.
When the carousel reaches its right-most extent, it may change its touch-action to pan-y pan-right so that a subsequent scroll operation beyond its extent can scroll the document within the viewport if possible.
It's not possible to change the behavior of a panning/scrolling operation while it is taking place.
auto user agents typically add 300ms of delay before click to allow for double-tap gestures to be handled. In these cases, explicitly setting touch-action: none or touch-action: manipulation will remove this delay. Note that the methods for determining a tap or double-tap gesture are out of scope for this specification.<div style="touch-action: none;">
This element receives pointer events for all direct manipulation interactions that otherwise lead to panning or zooming.
</div>
<div style="touch-action: pan-x;">
This element receives pointer events when not panning in the horizontal direction.
</div>
<div style="overflow: auto;">
<div style="touch-action: none;">
This element receives pointer events for all direct manipulation interactions that otherwise lead to panning or zooming.
</div>
<div>
Direct manipulation interactions on this element MAY be consumed for manipulating the parent.
</div>
</div>
<div style="overflow: auto;">
<div style="touch-action: pan-y;">
<div style="touch-action: pan-x;">
This element receives pointer events for all direct manipulation interactions because
it allows only horizontal panning yet an intermediate ancestor
(between it and the scrollable element) only allows vertical panning.
Therefore, no direct manipulation behaviors for panning/zooming are
handled by the user agent.
</div>
</div>
</div>
<div style="overflow: auto;">
<div style="touch-action: pan-y pan-left;">
<div style="touch-action: pan-x;">
This element receives pointer events when not panning to the left.
</div>
</div>
</div>
This section is non-normative.
Pointer capture allows the events for a particular pointer (including any compatibility mouse events) to be retargeted to a particular element other than the normal hit test result of the pointer's location. This is useful in scenarios like a custom slider control (e.g. similar to the [HTML] <input type="range"> control). Pointer capture can be set on the slider thumb element, allowing the user to slide the control back and forth even if the pointer slides off of the thumb.
pointerdown on the thumb, pointer capture can be used to allow the user to slide the thumb even if the pointer drifts off of it.Pointer capture is set on an element of type Element by calling the element.setPointerCapture(pointerId) method.
When this method is invoked, the user agent MUST run the following steps:
- If the
pointerIdprovided as the method's argument does not match any of the active pointers, then throw a "NotFoundError"DOMException. - Let the pointer be the active pointer specified by the given
pointerId. - If the element is not connected [DOM], throw an "
InvalidStateError"DOMException. - If this method is invoked while the element's node document [DOM] has a locked element ([PointerLock]
pointerLockElement), throw an "InvalidStateError"DOMException. - If the pointer is not in the active buttons state or the element's node document is not the active document of the pointer, then terminate these steps.
- For the specified
pointerId, set the pending pointer capture target override to theElementon which this method was invoked.
pointerdown listener.Pointer capture is released on an element explicitly by calling the element.releasePointerCapture(pointerId) method. When this method is called, the user agent MUST run the following steps:
- If the
pointerIdprovided as the method's argument does not match any of the active pointers and these steps are not being invoked as a result of the implicit release of pointer capture, then throw a "NotFoundError"DOMException. - If
hasPointerCaptureis false for theElementwith the specifiedpointerId, then terminate these steps. - For the specified
pointerId, clear the pending pointer capture target override, if set.
Inputs that implement direct manipulation interactions for panning and zooming (such as touch or stylus on a touchscreen) SHOULD behave exactly as if setPointerCapture was called on the target element just before the invocation of any pointerdown listeners. The hasPointerCapture API may be used (for instance, in a pointerdown listener) to determine whether this has occurred. If releasePointerCapture is not called for the pointer before the next pointer event is fired, then a gotpointercapture event will be dispatched to the target (as normal) indicating that capture is active.
Immediately after firing the pointerup or pointercancel events,
the user agent MUST clear the pending pointer capture target override
for the pointerId of the pointerup or pointercancel event that was just dispatched,
and then run process pending pointer capture steps to fire lostpointercapture if necessary.
After running process pending pointer capture steps,
if the pointer supports hover, user agent MUST also send corresponding boundary events necessary
to reflect the current position of the pointer with no capture.
When the pointer capture target override is no longer connected [DOM], the pointer capture target override SHOULD be set to the document.
When the pending pointer capture target override is no longer connected [DOM], the pending pointer capture target override node SHOULD be cleared.
lostpointercapture event
corresponding to the captured pointer being fired at the document
during the next Process pending pointer capture after the capture node is removed.
When a pointer lock [PointerLock] is successfully applied on an element, the user agent MUST run the steps as if the releasePointerCapture method has been called if any element is set to be captured or pending to be captured.
For performance reasons, user agents may choose not to send a pointermove
event every time a measurable property
(such as coordinates, pressure, tangential pressure, tilt, twist, or contact geometry)
of a pointer is updated. Instead, they may coalesce (combine/merge) multiple changes into
a single pointermove or pointerrawupdate event. While
this approach helps in reducing the amount of event handling the user agent MUST perform,
it will naturally reduce the granularity and fidelity when tracking a pointer position,
particularly for fast and large movements. Using the
getCoalescedEvents method
it is possible for applications to access the raw, un-coalesced position changes. These
allow for a more precise handling of pointer movement data. In the case of drawing
applications, for instance, the un-coalesced events can be used to draw smoother curves that
more closely match the actual movement of a pointer.
pointermove events (the grey dots), the curve is noticeably
angular and jagged; the same line drawn using the more granular points provided by
getCoalescedEvents() (the red circles) results in a smoother approximation
of the pointer movement.A PointerEvent has an associated coalesced events list (a list of
zero or more PointerEvents). For trusted pointermove and
pointerrawupdate events, the list is a sequence of all PointerEvents
that were coalesced into this event. The "parent" trusted pointermove and
pointerrawupdate event represents an accumulation of these coalesced events,
but may have additional processing (for example to align with the display refresh rate).
As a result, the coalesced events lists for these events always contain at least one event.
For all other trusted event types, it is an empty list. Untrusted events have their
coalesced events list initialized to the value passed to the constructor.
isTrusted bit of the event to false but the same bits in the coalesced events list remain unchanged from their original true values.
The events in the coalesced events list of a trusted event will have:
- Monotonically increasing
timeStampvalues [DOM] — all coalesced events have atimeStampthat is smaller than or equal to thetimeStampof the dispatched pointer event that thegetPredictedEventsmethod was called on. The coalesced events list MUST be chronologically sorted bytimeStamp, so the first event will have the smallesttimeStamp. - The same
pointerId,pointerType, andisPrimaryas the dispatched "parent" pointer event. - Empty coalesced events list and predicted events list of their own.
<style>
/* Disable intrinsic user agent direct manipulation behaviors (such as panning or zooming)
so that all events on the canvas element are given to the application instead. */
canvas { touch-action: none; }
</style>
<canvas id="drawSurface" width="500px" height="500px" style="border:1px solid black;"></canvas>
<script>
const canvas = document.getElementById("drawSurface"),
context = canvas.getContext("2d");
canvas.addEventListener("pointermove", (e)=> {
if (e.getCoalescedEvents) {
for (let coalesced_event of e.getCoalescedEvents()) {
paint(coalesced_event); // Paint all raw/non-coalesced points
}
} else {
paint(e); // Paint the final coalesced point
}
});
function paint(event) {
if (event.buttons>0) {
context.fillRect(event.clientX, event.clientY, 5, 5);
}
}
</script>
The order of all these dispatched events MUST match the actual order of the original events.
For example if a pointerdown event causes the dispatch for the
coalesced pointermove events the user agent MUST first dispatch one pointermove
event with all those coalesced events of a pointerId followed by the pointerdown event.
Here is an example of the actual events happening with increasing timeStamp values and the
events dispatched by the user agent:
| Actual events | Dispatched events |
|---|---|
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=1) coordinate change | pointerrawupdate (pointerId=1) w/ one coalesced event |
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=1) coordinate change | pointerrawupdate (pointerId=1) w/ one coalesced event |
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=1) button press |
pointermove (pointerId=1) w/ two coalesced eventspointermove (pointerId=2) w/ four coalesced eventspointerdown (pointerId=1) w/ zero coalesced events |
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=2) coordinate change | pointerrawupdate (pointerId=2) w/ one coalesced event |
pointer (pointerId=1) button release |
pointermove (pointerId=2) w/ two coalesced eventspointerup (pointerId=1) w/ zero coalesced events |
Some user agents have built-in algorithms which, after a series of confirmed pointer movements,
can make a prediction (based on the preceding events for the current gesture, and the speed/trajectory of the movement) what
the position of future pointer movements may be. Applications can use this information with
the getPredictedEvents method to speculatively "draw ahead" to a predicted position
to reduce perceived latency, and then discarding these predicted points once the actual points
are received.
pointermove events, showing the user agent's predicted future points (the grey circles).A PointerEvent has an associated predicted events list (a list of zero or more
PointerEvents). For trusted pointermove events, it is a sequence of
PointerEvents that the user agent predicts will follow the event in the future.
For all other trusted event types, it is an empty list.
Untrusted events have their predicted events list initialized to the value passed to the
constructor.
While pointerrawupdate events may have a non-empty coalesced events list,
their predicted events list will, for performance reasons, usually be an empty list.
isTrusted bit of the event to false but the same bits in the predicted events list remain unchanged from their original true values.
The number of events in the list and how far they are from the current timestamp are determined by the user agent and the prediction algorithm it uses.
The events in the predicted events list of a trusted event will have:
- Monotonically increasing
timeStampvalues [DOM] — all predicted events have atimeStampthat is greater than or equal to thetimeStampof the dispatched pointer event that thegetPredictedEventsmethod was called on. The predicted events list MUST be chronologically sorted bytimeStamp, so the first event will have the smallesttimeStamp. - The same
pointerId,pointerType, andisPrimaryas the dispatched "parent" pointer event. - Empty coalesced events list and predicted events list of their own.
Note that authors should only consider predicted events as valid predictions until the next pointer event is dispatched. It is possible, depending on how far into the future the user agent predicts events, that regular pointer events are dispatched earlier than the timestamp of one or more of the predicted events.
let predicted_points = [];
window.addEventListener("pointermove", function(event) {
// Clear the previously drawn predicted points.
for (let e of predicted_points.reverse()) {
clearPoint(e.pageX, e.pageY);
}
// Draw the actual movements that happened since the last received event.
for (let e of event.getCoalescedEvents()) {
drawPoint(e.pageX, e.pageY);
}
// Draw the current predicted points to reduce the perception of latency.
predicted_points = event.getPredictedEvents();
for (let e of predicted_points) {
drawPoint(e.pageX, e.pageY);
}
});
When a trusted PointerEvent is created, user agents SHOULD run the following steps for each event in the
coalesced events list and predicted events list:
- Set the event's
pointerId,pointerType,isPrimaryandisTrustedto match the respective properties of the "parent" pointer event. - Set the event's
cancelableandbubblesto false (as these events will never be dispatched in isolation). - Set the event's coalesced events list and predicted events list to an empty list.
- Initialize all other attributes to default
PointerEventvalues.
When a trusted PointerEvent's target is changed, user agents SHOULD, for each event in the
coalesced events list and predicted events list:
The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how the user agent MAY map generic pointer input to mouse events for compatibility with this content.
The compatibility mapping with mouse events is an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content.
At a high level, compatibility mouse events are intended to be "interleaved" with their respective pointer events. However, this specific order is not mandatory, and user agents that implement compatibility mouse events MAY decide to delay or group the dispatch of mouse events, as long as their relative order is consistent.
Particularly in the case of touchscreen inputs, user agents MAY apply additional heuristics for gesture recognition (unless explicitly suppressed by authors through ). During a sequence of events between a touch-actionpointerdown event and a pointerup event, the gesture recognition may have to wait until the pointerup event to detect or ignore a gesture. As a result the compatibility mouse events for the whole sequence may be dispatched together after the last pointerup event, if the user agent determined that an interaction was not intended as a particular gesture. These specifics of user agent gesture recognition are not defined in this specification, and they may differ between implementations.
Regardless of their support for compatibility mouse events, the user agents MUST always support the click, auxclick and contextmenu events because these events are of type PointerEvent and are therefore not compatibility mouse events. Calling preventDefault during a pointer event MUST NOT have an effect on whether click, auxclick, or contextmenu are fired or not.
The relative order of some of these high-level events (such as contextmenu, focus, blur) with pointer events is undefined and varies between user agents. For example, in some user agents contextmenu will often follow a pointerup, while in others it'll often precede a pointerup or pointercancel, and in some situations it may be fired without any corresponding pointer event (for instance, as a result of a keyboard interaction).
In addition, user agents may apply their own heuristics to determine whether or not a click, auxclick, or contextmenu event should be fired. Some user agents may choose not to fire these events if there are other (non-primary) pointers of the same type, or other primary pointers of a different type. User agents may determine that a particular action was not a "clean" tap, click, or long-press (for instance, if an interaction with a finger on a touch screen includes too much movement while the finger is in contact with the screen) and decide not to fire a click, auxclick, or contextmenu event. These aspects of user agent behavior are not defined in this specification, and they may differ between implementations.
Unless otherwise noted, the target of any mapped mouse event SHOULD be the same target as the respective pointer event unless the target is no longer participating in its ownerDocument's tree. In this case, the mouse event should be fired at the original target's nearest ancestor node (at the time it was removed from the tree) that still participates in its ownerDocument's tree, meaning that a new event path (based on the new target node) is built for the mouse event.
Authors can prevent the production of certain compatibility mouse events by canceling the pointerdown event.
Mouse events can only be prevented when the pointer is down. Hovering pointers (e.g. a mouse with no buttons pressed) cannot have their mouse events prevented.
The mouseover, mouseout, mouseenter, and mouseleave events are never prevented (even if the pointer is down).
Compatibility mouse events can't be prevented when a pointer event EventListener is set to be passive [DOM].
While only primary pointers can produce compatibility mouse events, multiple primary pointers can be active simultaneously, each producing its own compatibility mouse events. For compatibility with scripts relying on MouseEvents, the mouse transition events (mouseover, mouseout, mouseenter and mouseleave) SHOULD simulate the movement of a single legacy mouse input. This means that the entry/exit state for every event target is valid, in accordance with [UIEVENTS]. User agents SHOULD guarantee this by maintaining the effective position of the legacy mouse pointer in the document as follows.
Right before firing a pointerdown, pointerup or pointermove event, or a pointerleave event at the window, the user agent SHOULD run the following steps:
- Let T be the target of the
pointerdown,pointeruporpointermoveevent being dispatched. For thepointerleaveevent, unset T. - If T and current effective legacy mouse pointer position are both unset or they are equal, terminate these steps.
- Dispatch
mouseover,mouseout,mouseenterandmouseleaveevents as per [UIEVENTS] for a mouse moving from the current effective legacy mouse pointer position to T. Consider an unset value of either current effective legacy mouse pointer position or T as an out-of-window mouse position. - Set effective legacy mouse pointer position to T.
The effective position of the legacy mouse pointer models the fact that we cannot always have a direct mapping
from pointer transition events (pointerover, pointerout, pointerenter
and pointerleave) to corresponding legacy mouse transition events (mouseover,
mouseout, mouseenter and mouseleave). The following animation illustrates a case
where a user agent needs to dispatch more legacy mouse transition events than pointer transition events to be able to
reconcile two primary pointers using a single legacy mouse input.
In this animation, note the time period between the mouse click and the touch tap. Button 1 receives no
pointerout event (because the "real" mouse pointer didn't leave the button rectangle within
this period), but Button 1 receives a mouseout event when the effective position of the
legacy mouse pointer moves to Button 2 on touch tap. Similarly, in the time period between the touch
tap and the moment before the mouse leaves Button 1, Button 1 receives no pointerover event
for the same reason, but Button 1 receives a mouseover event when the effective position
of the legacy mouse pointer moves back inside Button 1.
Whenever the user agent is to dispatch a pointer event for a device that supports hover, it SHOULD run the following steps:
- If the
isPrimaryproperty for the pointer event to be dispatched isfalsethen dispatch the pointer event and terminate these steps. - If the pointer event to be dispatched is a
pointerdown,pointeruporpointermoveevent, or apointerleaveevent at thewindow, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer. - Dispatch the pointer event.
- If the pointer event dispatched was
pointerdownand event's canceled flag is set, then set thePREVENT MOUSE EVENTflag for thispointerType. - If the
PREVENT MOUSE EVENTflag is not set for thispointerTypeand the pointer event dispatched was:pointerdown, then fire amousedownevent.pointermove, then fire amousemoveevent.pointerup, then fire amouseupevent.pointercancel, then fire amouseupevent at thewindow.
- If the pointer event dispatched was
pointeruporpointercancel, clear thePREVENT MOUSE EVENTflag for thispointerType.
Some devices, such as most touchscreens, do not support hovering a coordinate (or set of coordinates) while not in the active state. Much existing content coded to mouse events assumes that a mouse is producing the events and thus certain qualities are generally true:
- The input can hover independently of activation (e.g. moving a mouse cursor without any buttons pressed).
- The input will likely produce the
mousemoveevent on an element before clicking it.
This requires that user agents provide a different mapping for these types of input devices. Whenever the user agent is to dispatch a pointer event for a device that does not support hover, it SHOULD run the following steps:
- If the
isPrimaryproperty for the pointer event to be dispatched isfalsethen dispatch the pointer event and terminate these steps. - If the pointer event to be dispatched is
pointeroverand thepointerdownevent has not yet been dispatched for this pointer, then fire amousemoveevent (for compatibility with legacy mouse-specific code). - If the pointer event to be dispatched is a
pointerdown,pointeruporpointermoveevent, or apointerleaveevent at thewindow, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer. - Dispatch the pointer event.
- If the pointer event dispatched was
pointerdownand event's canceled flag is set, then set thePREVENT MOUSE EVENTflag for thispointerType. - If the
PREVENT MOUSE EVENTflag is not set for thispointerTypeand the pointer event dispatched was:pointerdown, then fire amousedownevent.pointermove, then fire amousemoveevent.pointerup, then fire amouseupevent.pointercancel, then fire amouseupevent at thewindow.
- If the pointer event dispatched was
pointeruporpointercancel, clear thePREVENT MOUSE EVENTflag for thispointerType.
If the user agent supports both Touch Events (as defined in [TOUCH-EVENTS]) and Pointer Events, the user agent MUST NOT generate both the compatibility mouse events as described in this section, and the fallback mouse events outlined in [TOUCH-EVENTS].
The activation of an element (click) with a primary pointer that does not support hover (e.g. single finger on a touchscreen) would typically produce the following event sequence:
mousemovepointeroverpointerentermouseovermouseenterpointerdownmousedown- Zero or more
pointermoveandmousemoveevents, depending on movement of the pointer pointerupmouseuppointeroutpointerleavemouseoutmouseleaveclick
If, however, the pointerdown event canceled flag is set during this interaction then the sequence of events would be:
mousemovepointeroverpointerentermouseovermouseenterpointerdown- Zero or more
pointermoveevents, depending on movement of the pointer pointeruppointeroutpointerleavemouseoutmouseleaveclick
This appendix discusses security and privacy considerations for Pointer Events implementations. The discussion is limited to security and privacy issues that arise directly from implementation of the event model, APIs and events defined in this specification.
Many of the event types defined in this specification are dispatched in response to user actions. This allows malicious event listeners to gain access to information users would typically consider confidential, e.g., the exact path/movement of a user's mouse/stylus/finger while interacting with a page.
Pointer events contain additional information (where supported by the user's device), such as the angle or tilt at which a pen input is held, the geometry of the contact surface, and the pressure exerted on the stylus or touch screen. Information about angle, tilt, geometry and pressure are directly related to sensors on the user's device, meaning that this specification allows an origin access to these sensors.
This sensor data, as well as the ability to determine the type of input mechanism (mouse, touch, pen) used, may be used to infer characteristics of a user, or of the user's device and environment. These inferred characteristics and any device/environment information may themselves be sensitive — for instance, they may allow a malicious site to further infer if a user is using assistive technologies. This information can also be potentially used for the purposes of building a user profile and/or attempting to "fingerprint" and track a particular user.
As mitigation, user agents may consider including the ability for users to disable access to particular sensor data (such as angle, tilt, pressure), and/or to make it available only after an explicit opt-in from the user.
This specification defines the method by which authors can access "predicted events". The specification does not, itself, define the algorithms that user agents should use for their prediction. The specification authors envisage the algorithms to only rely on preceding pointer events related to the current gesture that a user is performing. It is the responsibility of user agents to ensure that their specific implementation of a prediction algorithm does not rely on any additional data - such as the user's full interaction history across different sites - that could reveal sensitive information about a user or be used to "fingerprint" and track them.
Beyond these considerations, the working group believes that this specification:
- Does not expose personally-identifiable information.
- Does not deal with high-value data.
- Does not introduce new state for an origin that persists across browsing sessions.
- Does not expose persistent, cross-origin state to the web.
- Does not expose any other data to an origin that it doesn’t currently have access to.
- Does not enable new script execution/loading mechanisms.
- Does not allow an origin access to a user’s location.
- Does not require any special handling when the user agent is in "incognito" mode.
- Does not allow an origin access to other devices.
- Does not allow an origin control over a user agent’s native UI.
- Does not expose temporary identifiers to the web.
- Does not distinguish between behavior in first-party and third-party contexts.
- Does not persist data to a user’s local device.
- Does not allow downgrading default security characteristics.
This section is non-normative.
- active buttons state
- The condition when a pointer has a non-zero value for the
buttonsproperty. For mouse, this is when the device has at least one button depressed. For touch, this is when there is physical contact with the digitizer. For pen, this is when either the pen has physical contact with the digitizer, or at least one button is depressed while hovering. - active document
- For every active pointer, the document that received the last event from that pointer.
- active pointer
- Any touch contact, pen/stylus, mouse cursor, or other pointer that can produce events. If it is possible for a given pointer (identified by a unique
pointerId) to produce additional events within the document, then that pointer is still considered active. Examples:- A mouse connected to the device is always active.
- A touch contact on the screen is considered active.
- If a touch contact or pen/stylus is lifted beyond the range of the digitizer, then it is no longer considered active.
NoteOn some platforms, the set of active pointers includes all pointer input to the device, including any that are not targeted at the user agent (e.g. those targeted at other applications). - contact geometry
- The bounding box of an input (most commonly, touch) on a digitizer. This typically refers to devices with coarser pointer input resolution than a single pixel. Some devices do not report this data at all.
- delta
- The estimated scroll amount (in pixels, lines, or pages) that the user agent will scroll or zoom the page in response to the physical movement of an input device that supports the
WheelEventinterface (such as a mouse wheel or touch pad). The value of a delta (e.g., thedeltaX,deltaY, ordeltaZattributes) is to be interpreted in the context of the currentdeltaModeproperty. The relationship between the physical movement of a wheel (or other device) and whether the delta is positive or negative is environment and device dependent. However, if a user agent scrolls as the default action then the sign of the delta is 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. - digitizer
- A type of input sensing device in which a surface can detect input which is in contact and/or in close proximity. Most commonly, this is the surface that senses input from the touch contact or a pen/stylus.
- direct manipulation
- Certain user agents (such as browsers on a touchscreen device) implement a "direct manipulation" metaphor where a pointer not only interacts with controls, but
is also used to directly pan or zoom the current page, providing the illusion of direct physical contact. As an example, users on a touchscreen device are generally
able to use a finger or a stylus to "grab" a page and pan it by moving the pointer, directly manipulating the page. Contrast this with a mouse pointer on a regular
desktop/laptop, where panning is done by using a scrollbar, rather than by "dragging" the page.
NoteIn some cases, touchpads (like those found on a laptop) will allow the user to scroll by "dragging" on the touchpad. However, this is generally achieved by the touchpad generating "fake" mouse wheel events, so this wouldn't count as a direct manipulation.
- hysteresis
- A feature of human interface design to accept input values within a certain range of location or time, in order to improve the user experience. For example, allowing for small deviation in the time it takes for a user to double-click a mouse button is temporal hysteresis, and not immediately closing a nested menu if the user mouses out from the parent window when transitioning to the child menu is locative hysteresis.
- measurable properties
Measurable properties represent values relating to continuous pointer sensor data that is expressed using a real number or an integer from a large domain. For pointer events,
width,height,pressure,tangentialPressure,tiltX,tiltY,twist,altitudeAngle,azimuthAngle, and the [UIEVENTS] Mouse Event model propertiesscreenX,screenY,clientX,clientYare measurable properties.In contrast
pointerId,pointerType,isPrimary, and the [UIEVENTS] Mouse Event model propertiesbutton,buttons,ctrlKey,shiftKey,altKey, andmetaKeyare not considered measurable properties, as they don't relate to sensor data.- pointer
- A hardware-agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact.
- rotation
- An indication of incremental change on an input device using the
WheelEventinterface. On some devices this MAY be a literal rotation of a wheel, while on others, it MAY be movement along a flat surface, or pressure on a particular button. - topmost event target
- The topmost event target MUST be the element highest in the rendering order which is capable of being a target. In graphical user interfaces this is the element under the user's pointing device. A user interface's
hit testing
facility is used to determine the target. For specific details regarding hit testing and stacking order, refer to the host language.
This section is normative. The following features are obsolete and should only be implemented by user agents that require compatibility with legacy software. See also the legacy event initializers in [UIEvents].
WebIDLpartial interface MouseEvent {
};
- initMouseEvent(typeArg)
-
Initializes attributes of a
MouseEventobject. This method has the same behavior asUIEvent.initUIEvent().WarningThe
initMouseEventmethod is deprecated, but supported for backwards-compatibility with widely-deployed implementations.- DOMString typeArg
-
Refer to the
initEvent()method for a description of this parameter. - boolean bubblesArg
-
Refer to the
initEvent()method for a description of this parameter. - boolean cancelableArg
-
Refer to the
initEvent()method for a description of this parameter. - Window? viewArg
-
Specifies
view. This value MAY benull. - long detailArg
-
Specifies
detail. - long screenXArg
-
Specifies
screenX. - long screenYArg
-
Specifies
screenY. - long clientXArg
-
Specifies
clientX. - long clientYArg
-
Specifies
clientY. - boolean ctrlKeyArg
-
Specifies
ctrlKey. - boolean altKeyArg
-
Specifies
altKey. - boolean shiftKeyArg
-
Specifies
shiftKey. - boolean metaKeyArg
-
Specifies
metaKey. - short buttonArg
-
Specifies
button. - EventTarget? relatedTargetArg
-
Specifies
relatedTarget. This value MAY benull.
Many thanks to lots of people for their proposals and recommendations, some of which are incorporated into this document. The group's Chair acknowledges contributions from the following past and present group members and participants: Mustaq Ahmed, Arthur Barstow, Ben Boyle, Matt Brubeck, Rick Byers, Marcos Cáceres, Cathy Chan, Bo Cupp, Domenic Denicola, Ted Dinklocker, Adam Ettenberger, Robert Flack, Dave Fleck, Mike Fraser, Ella Ge, Olga Gerchikov, Scott González, Kartikaya Gupta, Dominique Hazael-Massieux, Philippe Le Hégaret, Hayato Ito, Patrick Kettner, Patrick H. Lauke, Scott Low, Sangwhan Moon, Masayuki Nakano, Olli Pettay, Addison Phillips, Alan Pyne, Antoine Quint, Jacob Rossi, Kagami Sascha Rosylight, Doug Schepers, Ming-Chou Shih, Brenton Simpson, Dave Tapuska, Liviu Tinta, Asir Vedamuthu, Lan Wei, Jeffrey Yasskin, Navid Zolghadr.
Thanks to those who took care of mouse and wheel events in the past: Gary Kacmarcik, Travis Leithead, and the various contributors over the years.
Special thanks to those that helped pioneer the first edition of this model, including especially: Charu Chandiram, Peter Freiling, Nathan Furtwangler, Thomas Olsen, Matt Rakow, Ramu Ramanathan, Justin Rogers, Jacob Rossi, Reed Townsend and Steve Wright.
This section is non-normative.
The following is an informative summary of substantial and major editorial changes between publications of this specification, relative to the [PointerEvents3] specification. See the complete revision history of the Editor's Drafts of this specification.
WebIDL[Exposed=Window]
interface MouseEvent : UIEvent {
constructor(DOMString type, optional MouseEventInit eventInitDict = {});
readonly attribute long screenX;
readonly attribute long screenY;
readonly attribute long clientX;
readonly attribute long clientY;
readonly attribute long layerX;
readonly attribute long layerY;
readonly attribute boolean ctrlKey;
readonly attribute boolean shiftKey;
readonly attribute boolean altKey;
readonly attribute boolean metaKey;
readonly attribute short button;
readonly attribute unsigned short buttons;
readonly attribute EventTarget? relatedTarget;
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;
};
dictionary PointerEventInit : MouseEventInit {
long pointerId = 0;
double width = 1;
double height = 1;
float pressure = 0;
float tangentialPressure = 0;
long tiltX;
long tiltY;
long twist = 0;
double altitudeAngle;
double azimuthAngle;
DOMString pointerType = "";
boolean isPrimary = false;
long persistentDeviceId = 0;
sequence<PointerEvent> coalescedEvents = [];
sequence<PointerEvent> predictedEvents = [];
};
[Exposed=Window]
interface PointerEvent : MouseEvent {
constructor(DOMString type, optional PointerEventInit eventInitDict = {});
readonly attribute long pointerId;
readonly attribute double width;
readonly attribute double height;
readonly attribute float pressure;
readonly attribute float tangentialPressure;
readonly attribute long tiltX;
readonly attribute long tiltY;
readonly attribute long twist;
readonly attribute double altitudeAngle;
readonly attribute double azimuthAngle;
readonly attribute DOMString pointerType;
readonly attribute boolean isPrimary;
readonly attribute long persistentDeviceId;
[SecureContext] sequence<PointerEvent> getCoalescedEvents();
sequence<PointerEvent> getPredictedEvents();
};
[Exposed=Window]
interface WheelEvent : MouseEvent {
constructor(DOMString type, optional WheelEventInit eventInitDict = {});
// 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;
};
partial interface Element {
undefined setPointerCapture (long pointerId);
undefined releasePointerCapture (long pointerId);
boolean hasPointerCapture (long pointerId);
};
partial interface mixin GlobalEventHandlers {
attribute EventHandler onpointerover;
attribute EventHandler onpointerenter;
attribute EventHandler onpointerdown;
attribute EventHandler onpointermove;
[SecureContext] attribute EventHandler onpointerrawupdate;
attribute EventHandler onpointerup;
attribute EventHandler onpointercancel;
attribute EventHandler onpointerout;
attribute EventHandler onpointerleave;
attribute EventHandler ongotpointercapture;
attribute EventHandler onlostpointercapture;
};
partial interface Navigator {
readonly attribute long maxTouchPoints;
};
partial interface MouseEvent {
// Deprecated in this specification
undefined initMouseEvent(DOMString typeArg,
optional boolean bubblesArg = false,
optional boolean cancelableArg = false,
optional Window? viewArg = null,
optional long detailArg = 0,
optional long screenXArg = 0,
optional long screenYArg = 0,
optional long clientXArg = 0,
optional long clientYArg = 0,
optional boolean ctrlKeyArg = false,
optional boolean altKeyArg = false,
optional boolean shiftKeyArg = false,
optional boolean metaKeyArg = false,
optional short buttonArg = 0,
optional EventTarget? relatedTargetArg = null);
};- [CSS-OVERFLOW-3]
- CSS Overflow Module Level 3. Elika Etemad; Florian Rivoal. W3C. 7 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/css-overflow-3/
- [css-position]
- CSS Positioned Layout Module Level 3. Elika Etemad; Tab Atkins Jr. W3C. 7 October 2025. W3C Working Draft. URL: https://www.w3.org/TR/css-position-3/
- [CSS21]
- Cascading Style Sheets Level 2 Revision 1 (CSS 2.1) Specification. Bert Bos; Tantek Çelik; Ian Hickson; Håkon Wium Lie. W3C. 7 June 2011. W3C Recommendation. URL: https://www.w3.org/TR/CSS2/
- [CSSOM-View]
- CSSOM View Module. Simon Fraser; Emilio Cobos Álvarez. W3C. 16 September 2025. W3C Working Draft. URL: https://www.w3.org/TR/cssom-view-1/
- [DOM]
- DOM Standard. Anne van Kesteren. WHATWG. Living Standard. URL: https://dom.spec.whatwg.org/
- [ECMASCRIPT]
- ECMAScript Language Specification. Ecma International. URL: https://tc39.es/ecma262/multipage/
- [HTML]
- HTML Standard. Anne van Kesteren; Domenic Denicola; Dominic Farolino; Ian Hickson; Philip Jägenstedt; Simon Pieters. WHATWG. Living Standard. URL: https://html.spec.whatwg.org/multipage/
- [HTML401]
- HTML 4.01 Specification. Dave Raggett; Arnaud Le Hors; Ian Jacobs. W3C. 27 March 2018. W3C Recommendation. URL: https://www.w3.org/TR/html401/
- [infra]
- Infra Standard. Anne van Kesteren; Domenic Denicola. WHATWG. Living Standard. URL: https://infra.spec.whatwg.org/
- [PointerEvents]
- Pointer Events. Patrick Lauke; Robert Flack. W3C. 11 February 2026. W3C Working Draft. URL: https://www.w3.org/TR/pointerevents4/
- [PointerLock]
- Pointer Lock 2.0. Mustaq Ahmed; Vincent Scheib. W3C. 25 February 2026. W3C Working Draft. URL: https://www.w3.org/TR/pointerlock-2/
- [RFC2119]
- Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. IETF. March 1997. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc2119
- [RFC8174]
- Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words. B. Leiba. IETF. May 2017. Best Current Practice. URL: https://www.rfc-editor.org/rfc/rfc8174
- [TOUCH-EVENTS]
- Touch Events. Doug Schepers; Sangwhan Moon; Matt Brubeck; Arthur Barstow. W3C. 10 October 2013. W3C Recommendation. URL: https://www.w3.org/TR/touch-events/
- [UIEVENTS]
- UI Events. Xiaoqian Wu. W3C. 21 February 2026. W3C Working Draft. URL: https://www.w3.org/TR/uievents/
- [UIEvents-Key]
- UI Events KeyboardEvent key Values. Travis Leithead; Gary Kacmarcik. W3C. 22 April 2025. W3C Recommendation. URL: https://www.w3.org/TR/uievents-key/
- [WEBDRIVER-BIDI]
- WebDriver BiDi. James Graham; Alex Rudenko; Maksim Sadym. W3C. 25 February 2026. W3C Working Draft. URL: https://www.w3.org/TR/webdriver-bidi/
- [WEBIDL]
- Web IDL Standard. Edgar Chen; Timothy Gu. WHATWG. Living Standard. URL: https://webidl.spec.whatwg.org/
- [COMPAT]
- Compatibility Standard. Mike Taylor. WHATWG. Living Standard. URL: https://compat.spec.whatwg.org/
- [PointerEvents3]
- Pointer Events. Patrick Lauke; Robert Flack. W3C. 13 February 2026. CRD. URL: https://www.w3.org/TR/pointerevents3/
- [WCAG22]
- Web Content Accessibility Guidelines (WCAG) 2.2. Michael Cooper; Andrew Kirkpatrick; Alastair Campbell; Rachael Bradley Montgomery; Charles Adams. W3C. 12 December 2024. W3C Recommendation. URL: https://www.w3.org/TR/WCAG22/
Referenced in:
- § 4.1 Interface MouseEvent (2) (3) (4)
- § 4.1.1 MouseEvent
- § 4.1.2 MouseEventInit (2) (3) (4) (5) (6)
- § 4.2.2 Constructing Mouse Events (2) (3) (4) (5)
- § 4.2.4 Internal State for MouseEvent
- § 4.2.6 initialize a MouseEvent
- § 4.2.7 set mouse event modifiers
- § 4.2.8 create a cancelable MouseEvent (2)
- § 4.2.9 create a non-cancelable MouseEvent (2)
- § 4.2.10 calculate MouseEvent button attribute
- § 4.2.11 set MouseEvent attributes from native
- § 4.4.1 auxclick (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- § 4.4.2 click (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- § 4.4.3 contextmenu (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13)
- § 4.4.4 dblclick (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.5 mousedown (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.6 mouseenter (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.7 mouseleave (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.8 mousemove (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.9 mouseout (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.10 mouseover (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 4.4.11 mouseup (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14)
- § 5.1 PointerEvent interface (2) (3)
- § 5.1.1.1 Chorded button interactions
- § 5.2.3 create PointerEvent from MouseEvent (2)
- § 5.2.4 maybe send pointerout event
- § 5.2.5 maybe send pointerleave event
- § 5.2.6 maybe send pointerover event
- § 5.2.7 maybe send pointerenter event
- § 5.2.8 maybe send pointermove event
- § 5.2.9 maybe send pointerdown event (2)
- § 5.2.10 maybe send pointerrawupdate event
- § 5.2.11 maybe send pointerup event (2)
- § 5.3.12.2 Event coordinates
- § 6.1.1 WheelEvent
- § 6.2.1 wheel (2) (3) (4) (5) (6) (7) (8) (9) (10) (11)
- § 16.1 Initializers for interface MouseEvent (2)
- § C. IDL Index (2) (3)
Referenced in:
- § 4.1.1 MouseEvent
- § 4.1.2 MouseEventInit
- § 4.2.6 initialize a MouseEvent
- § 4.2.15 send click event
- § 4.2.16 handle native mouse double click
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent
- § 4.1.2 MouseEventInit
- § 4.2.6 initialize a MouseEvent
- § 4.2.15 send click event
- § 4.2.16 handle native mouse double click
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1 Interface MouseEvent
- § 4.1.1 MouseEvent
- § 4.1.2 MouseEventInit
- § 4.2.6 initialize a MouseEvent
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1 Interface MouseEvent
- § 4.1.1 MouseEvent
- § 4.1.2 MouseEventInit
- § 4.2.6 initialize a MouseEvent
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
Referenced in:
Referenced in:
- § 4.1.1 MouseEvent
- § 4.2.7 set mouse event modifiers
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent
- § 4.2.7 set mouse event modifiers
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent
- § 4.2.7 set mouse event modifiers
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent
- § 4.2.7 set mouse event modifiers
- § 4.4.1 auxclick
- § 4.4.2 click
- § 4.4.3 contextmenu
- § 4.4.4 dblclick
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent (2) (3) (4) (5) (6)
- § 4.1.2 MouseEventInit
- § 4.2.6 initialize a MouseEvent
- § 4.2.10 calculate MouseEvent button attribute
- § 4.2.11 set MouseEvent attributes from native
- § 4.4.1 auxclick (2) (3)
- § 4.4.2 click (2) (3)
- § 4.4.3 contextmenu
- § 4.4.4 dblclick (2)
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § 16.1 Initializers for interface MouseEvent
- § C. IDL Index
Referenced in:
- § 4.1.1 MouseEvent (2) (3) (4) (5)
- § 4.1.2 MouseEventInit (2) (3)
- § 4.2.6 initialize a MouseEvent
- § 4.4.1 auxclick (2) (3)
- § 4.4.2 click (2) (3)
- § 4.4.3 contextmenu
- § 4.4.4 dblclick (2)
- § 4.4.5 mousedown
- § 4.4.6 mouseenter
- § 4.4.7 mouseleave
- § 4.4.8 mousemove
- § 4.4.9 mouseout
- § 4.4.10 mouseover
- § 4.4.11 mouseup
- § 6.2.1 wheel
- § C. IDL Index
Referenced in:
Referenced in:
Referenced in:
- § 4.2.12 handle native mouse down
- § 4.2.13 handle native mouse up
- § 4.2.14 handle native mouse click
- § 4.2.16 handle native mouse double click
- § 4.2.17 handle native mouse move
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.4 Boundary events caused by layout changes
- § 5.3.1 The pointerover event
- § 5.3.2 The pointerenter event (2)
- § 5.3.8 The pointerout event
- § 5.3.9 The pointerleave event (2)
- § 11.1 Introduction
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 5.1 PointerEvent interface (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)
- § 5.1.3 Firing events using the PointerEvent interface (2)
- § 5.1.3.3 Suppressing a pointer event stream
- § 5.3.5 The pointerrawupdate event
- § 5.3.7 The pointercancel event
- § 5.3.12.1 Event attributes (2) (3)
- § 5.3.12.3 Event dispatch
- § 7. Extensions to the Element interface (2) (3) (4)
- § 11.2 Setting pointer capture (2) (3)
- § 11.3 Releasing pointer capture (2) (3)
- § 11.5 Implicit release of pointer capture
- § 12.1 Coalesced events (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12) (13) (14) (15) (16) (17) (18) (19) (20) (21) (22) (23) (24) (25)
- § 12.2 Predicted events
- § 12.3 Populating and maintaining the coalesced and predicted events lists
- § 15. Glossary (2)
- § C. IDL Index
Referenced in:
Referenced in:
Referenced in:
- § 4.4.1 auxclick (2)
- § 4.4.2 click (2)
- § 4.4.3 contextmenu
- § 5.1 PointerEvent interface (2) (3) (4) (5) (6) (7)
- § 5.1.3 Firing events using the PointerEvent interface (2)
- § 5.2.1 initialize a PointerEvent (2)
- § 5.2.2 create a PointerEvent (2)
- § 5.2.3 create PointerEvent from MouseEvent
- § 5.3.12.2 Event coordinates (2) (3)
- § 12.1 Coalesced events
- § 12.2 Predicted events
- § 12.3 Populating and maintaining the coalesced and predicted events lists (2) (3)
- § C. IDL Index (2) (3) (4) (5)
Referenced in:
Referenced in:
Referenced in:
- § 5.1 PointerEvent interface
- § 5.3.1 The pointerover event
- § 5.3.2 The pointerenter event
- § 5.3.3 The pointerdown event (2)
- § 5.3.4 The pointermove event
- § 5.3.5 The pointerrawupdate event
- § 5.3.6 The pointerup event (2)
- § 5.3.7 The pointercancel event
- § 5.3.8 The pointerout event
- § 5.3.9 The pointerleave event
- § 5.3.10 The gotpointercapture event
- § 5.3.11 The lostpointercapture event
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
- § 1. Introduction
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.3.1 Attributes and default actions (2)
- § 5.1.4 Boundary events caused by layout changes
- § 5.3.1 The pointerover event
- § 5.3.2 The pointerenter event
- § 5.3.3 The pointerdown event
- § 8. Extensions to the GlobalEventHandlers mixin
- § 13.3 Mapping for devices that do not support hover (2) (3)
Referenced in:
Referenced in:
- § 1. Introduction
- § 5.1.1.1 Chorded button interactions
- § 5.1.1.2 The button property
- § 5.1.3 Firing events using the PointerEvent interface (2)
- § 5.1.3.1 Attributes and default actions
- § 5.2.9 maybe send pointerdown event
- § 5.3.1 The pointerover event (2)
- § 5.3.2 The pointerenter event (2)
- § 5.3.3 The pointerdown event (2) (3) (4)
- § 5.3.4 The pointermove event
- § 5.3.6 The pointerup event
- § 5.3.12.3 Event dispatch
- § 7. Extensions to the Element interface
- § 8. Extensions to the GlobalEventHandlers mixin
- § 10.1 The touch-action CSS property (2)
- § 10.2 Determining supported direct manipulation behavior
- § 11.1 Introduction
- § 11.2 Setting pointer capture
- § 11.4 Implicit pointer capture (2)
- § 12.1 Coalesced events (2) (3)
- § 13. Compatibility mapping with mouse events (2)
- § 13.1 Tracking the effective position of the legacy mouse pointer (2)
- § 13.2 Mapping for devices that support hover (2) (3)
- § 13.3 Mapping for devices that do not support hover (2) (3) (4) (5) (6) (7)
Referenced in:
- § 1. Introduction
- § 5.1.1.2 The button property (2)
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.3.1 Attributes and default actions
- § 5.1.4 Boundary events caused by layout changes
- § 5.3.4 The pointermove event (2) (3)
- § 5.3.5 The pointerrawupdate event (2) (3) (4) (5) (6) (7) (8) (9)
- § 8. Extensions to the GlobalEventHandlers mixin
- § 12.1 Coalesced events (2) (3) (4) (5) (6) (7) (8) (9) (10)
- § 12.2 Predicted events (2)
- § 13.1 Tracking the effective position of the legacy mouse pointer (2)
- § 13.2 Mapping for devices that support hover (2)
- § 13.3 Mapping for devices that do not support hover (2) (3) (4)
Referenced in:
Referenced in:
- § 1. Introduction
- § 5.1.1.1 Chorded button interactions
- § 5.1.1.2 The button property
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.3.1 Attributes and default actions
- § 5.2.11 maybe send pointerup event
- § 5.3.3 The pointerdown event
- § 5.3.4 The pointermove event
- § 5.3.6 The pointerup event (2) (3) (4)
- § 5.3.8 The pointerout event (2)
- § 5.3.9 The pointerleave event (2)
- § 5.3.12.3 Event dispatch (2)
- § 8. Extensions to the GlobalEventHandlers mixin
- § 10.1 The touch-action CSS property
- § 11.5 Implicit release of pointer capture (2)
- § 12.1 Coalesced events
- § 13. Compatibility mapping with mouse events (2) (3) (4) (5)
- § 13.1 Tracking the effective position of the legacy mouse pointer (2)
- § 13.2 Mapping for devices that support hover (2) (3)
- § 13.3 Mapping for devices that do not support hover (2) (3) (4) (5)
Referenced in:
- § 5.1.3.1 Attributes and default actions
- § 5.1.3.3 Suppressing a pointer event stream
- § 5.3.7 The pointercancel event (2) (3)
- § 8. Extensions to the GlobalEventHandlers mixin
- § 10.1 The touch-action CSS property
- § 11.5 Implicit release of pointer capture (2)
- § 13. Compatibility mapping with mouse events
- § 13.2 Mapping for devices that support hover (2)
- § 13.3 Mapping for devices that do not support hover (2)
Referenced in:
- § 1. Introduction
- § 5.1.3.1 Attributes and default actions (2)
- § 5.1.3.3 Suppressing a pointer event stream
- § 5.1.4 Boundary events caused by layout changes
- § 5.3.6 The pointerup event
- § 5.3.8 The pointerout event
- § 5.3.9 The pointerleave event
- § 8. Extensions to the GlobalEventHandlers mixin
- § 13.3 Mapping for devices that do not support hover (2)
Referenced in:
- § 5.1.3.1 Attributes and default actions (2) (3)
- § 5.1.3.3 Suppressing a pointer event stream
- § 5.1.4 Boundary events caused by layout changes
- § 5.3.2 The pointerenter event
- § 5.3.6 The pointerup event
- § 5.3.9 The pointerleave event (2)
- § 8. Extensions to the GlobalEventHandlers mixin
- § 13.1 Tracking the effective position of the legacy mouse pointer (2)
- § 13.2 Mapping for devices that support hover
- § 13.3 Mapping for devices that do not support hover (2) (3)
Referenced in:
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.3.1 Attributes and default actions (2) (3)
- § 5.1.3.2 Process pending pointer capture (2)
- § 5.3 Pointer Event types
- § 5.3.10 The gotpointercapture event
- § 7. Extensions to the Element interface
- § 8. Extensions to the GlobalEventHandlers mixin
- § 11.4 Implicit pointer capture
Referenced in:
- § 5.1.3 Firing events using the PointerEvent interface
- § 5.1.3.1 Attributes and default actions (2) (3)
- § 5.1.3.2 Process pending pointer capture (2) (3)
- § 5.3 Pointer Event types
- § 5.3.11 The lostpointercapture event
- § 5.3.12.3 Event dispatch
- § 8. Extensions to the GlobalEventHandlers mixin
- § 11.5 Implicit release of pointer capture (2)
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in:
Referenced in: