From a9bbc3cc5ff4d28443573aed9b265dfd73a50441 Mon Sep 17 00:00:00 2001 From: "Patrick H. Lauke" Date: Wed, 8 Jun 2016 23:49:57 +0100 Subject: [PATCH] Initial code cleanup Fixes some markup validation issues (caused by mismatched opening/closing tags), harmonize use of `
` vs `
`, remove some redundant block level elements, add `

...

` where needed, initial attempt at fixing main code indentation --- index.html | 1172 ++++++++++++++++++++++++++-------------------------- 1 file changed, 581 insertions(+), 591 deletions(-) diff --git a/index.html b/index.html index 3219bd4..df02e8c 100644 --- a/index.html +++ b/index.html @@ -91,44 +91,47 @@
- The features in this specification extend or modify those found in [[PointerEvents]], a W3C Recomendation that describes events and related interfaces for handling hardware agnostic pointer input from devices including a mouse, pen, touchscreen, etc. For compatibility with existing mouse based content, this specification also describes a mapping to fire [[DOM-LEVEL-3-EVENTS]] Mouse Events for other pointer device types. +

The features in this specification extend or modify those found in [[PointerEvents]], a W3C Recomendation that describes events and related interfaces for handling hardware agnostic pointer input from devices including a mouse, pen, touchscreen, etc. For compatibility with existing mouse based content, this specification also describes a mapping to fire [[DOM-LEVEL-3-EVENTS]] Mouse Events for other pointer device types.

-

This specification is an update to Pointer Events Level 1 which was shipped broadly only by Microsoft Internet Explorer and Microsoft Edge (though a further independent and mostly interoperable implementation was present in a pre-release build of Mozilla Firefox when the Pointer Events specification was published as a W3C Recommendation). Level 2 includes editorial clarifications, new features and minor breaking changes that address certain limitations and concerns that have been raised about aspects of the design, in an effort to enable wider browser adoption.

+

This specification is an update to Pointer Events Level 1 which was shipped broadly only by Microsoft Internet Explorer and Microsoft Edge (though a further independent and mostly interoperable implementation was present in a pre-release build of Mozilla Firefox when the Pointer Events specification was published as a W3C Recommendation). Level 2 includes editorial clarifications, new features and minor breaking changes that address certain limitations and concerns that have been raised about aspects of the design, in an effort to enable wider browser adoption.

-

Introduction

-

Today, most [[HTML5]] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [[!DOM-LEVEL-3-EVENTS]] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens, pen input, etc. 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 specifications 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 default touch actions, such as scrolling, 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 screenreader 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.

+

Introduction

+

Today, most [[HTML5]] content is used with and/or designed for mouse input. Those that handle input in a custom manner typically code to [[!DOM-LEVEL-3-EVENTS]] Mouse Events. Newer computing devices today, however, incorporate other forms of input, including touchscreens, pen input, etc. 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 specifications 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 default touch actions, such as scrolling, 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 screenreader 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 WCAG 2.0 Guideline 2.1 for further details.

-
-
- Pointer input combines input from mouse, pen, touch, etc. -
A pointer is a hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen.
-
+

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 WCAG 2.0 Guideline 2.1 for further details.

+
+ +
+ Pointer input combines input from mouse, pen, touch, etc. +
A pointer is a hardware agnostic representation of input devices that can target a specific coordinate (or set of coordinates) on a screen.
+
-

The events for handling generic pointer input look a lot like those for mouse: pointerdown, pointermove, pointerup, pointerover, pointerout, etc. This facilitates easy content migration from Mouse Events to Pointer Events. +

The events for handling generic pointer input look a lot like those for mouse: pointerdown, pointermove, pointerup, pointerover, pointerout, etc. This facilitates easy content migration from Mouse Events to Pointer Events. Pointer Events provide all the usual properties present in Mouse Events (client coordinates, target element, button states, etc.) in addition to new properties for other forms of input: pressure, contact geometry, tilt, etc. So 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 (e.g. mouse events, touch events, etc.). 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 Pointer Events and Touch Events. For more information on the relationship between these two specifications, see the Touch Events Community Group. -
+

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 (e.g. mouse events, touch events, etc.). 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 Pointer Events and Touch Events. For more information on the relationship between these two specifications, see the Touch Events Community Group.

+
+ +
-
+
-
-
-
-

Examples

-

The following are example author code that demonstrates how the APIs in this specification might be used.

+
+

Examples

+

The following are example author code that demonstrates how the APIs in this specification might be used.

 <style>
   /* Disable intrinsic user agent touch behaviors (such as panning or zooming) so 
@@ -202,7 +205,8 @@ 
Examples

     });
 eventTarget.dispatchEvent(event);
-
+
+

Glossary

@@ -234,179 +238,176 @@

Glossary

Adding the task to events task queue of the relevant event loop, as defined in [[!HTML5]].
-
-

Pointer Events and Interfaces

-
-

PointerEvent Interface

-
-
-
readonly attribute long pointerId
-
-

A unique identifier for the pointer causing the event. This identifier MUST be unique from all other active pointers in the top-level browsing context (as defined by [[!HTML5]]) at the time. A user agent MAY recycle previously retired values for pointerId from previous active pointers, if necessary.

- -
The pointerId selection algorithm is implementation specific. Therefore 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, values are not guaranteed to be monotonically increasing.
-
-
readonly attribute double 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. -
-
readonly attribute double 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. -
-
readonly attribute float pressure
-
- The normalized pressure of the pointer input in the range of [0,1], where 0 and 1 represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware that does not support pressure, the value MUST be 0.5 when in the active buttons state and 0 otherwise. -
-
readonly attribute long 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 positive tiltX is to the right. tiltX can be used along with tiltY to represent the tilt away from the normal of a transducer with the digitizer. For devices that do not report tilt, the value MUST be 0.

-
- tiltX explanation diagram -
Positive tiltX.
-
-
-
readonly attribute long 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 positive tiltY is towards the user. tiltY can be used along with tiltX to represent the tilt away from the normal of a transducer with the digitizer. For devices that do not report tilt, the value MUST be 0. -
- tiltY explanation diagram -
Negative tiltY.
-
-
-
readonly attribute long 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 devices that do not report twist, the value MUST be 0. -
-
readonly attribute DOMString pointerType
-
-

Indicates the device type that caused the event (mouse, pen, touch, etc.). If a user agent is to fire a pointer event for a mouse, pen stylus, or touch input device, then the value of pointerType MUST be according to the following table:

+ +
+

Pointer Events and Interfaces

+
+

PointerEvent Interface

+
+
+
readonly attribute long pointerId
+
+

A unique identifier for the pointer causing the event. This identifier MUST be unique from all other active pointers in the top-level browsing context (as defined by [[!HTML5]]) at the time. A user agent MAY recycle previously retired values for pointerId from previous active pointers, if necessary.

+ +
The pointerId selection algorithm is implementation specific. Therefore 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, values are not guaranteed to be monotonically increasing.
+
+
readonly attribute double 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. +
+
readonly attribute double 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. +
+
readonly attribute float pressure
+
+ The normalized pressure of the pointer input in the range of [0,1], where 0 and 1 represent the minimum and maximum pressure the hardware is capable of detecting, respectively. For hardware that does not support pressure, the value MUST be 0.5 when in the active buttons state and 0 otherwise. +
+
readonly attribute long 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 positive tiltX is to the right. tiltX can be used along with tiltY to represent the tilt away from the normal of a transducer with the digitizer. For devices that do not report tilt, the value MUST be 0.

+
+ tiltX explanation diagram +
Positive tiltX.
+
+
+
readonly attribute long 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 positive tiltY is towards the user. tiltY can be used along with tiltX to represent the tilt away from the normal of a transducer with the digitizer. For devices that do not report tilt, the value MUST be 0. +
+ tiltY explanation diagram +
Negative tiltY.
+
+
+
readonly attribute long 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 devices that do not report twist, the value MUST be 0. +
+
readonly attribute DOMString pointerType
+
+

Indicates the device type that caused the event (mouse, pen, touch, etc.). If a user agent is to fire a pointer event for a mouse, pen stylus, or touch input device, then the value of pointerType MUST be according to the following table:

+ + + + + + + + + +
Pointer Device TypepointerType Value
Mousemouse
Pen Styluspen
Touch Contacttouch
+

If the device type cannot be detected by the user agent, then the value MUST be an empty string. If a user agent supports pointer device types other than those listed above, the value of pointerType SHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types.

+
See Example 2 for a basic demonstration of how the pointerType can be used. Also note that developers should include some form of default handling to cover user agents that may have implemented their own custom pointerType values and for situations where pointerType is simply an empty string.
+
+
readonly attribute boolean isPrimary
+
+ Indicates if the pointer represents the primary pointer of this pointer type. +
+
+
+
long pointerId = 0
+
Initializes the pointerId property of the PointerEvent object.
+
double width = 1
+
Initializes the width property of the PointerEvent object.
+
double height = 1
+
Initializes the height property of the PointerEvent object.
+
float pressure = 0
+
Initializes the pressure property of the PointerEvent object.
+
long tiltX = 0
+
Initializes the tiltX property of the PointerEvent object.
+
long tiltY = 0
+
Initializes the tiltY property of the PointerEvent object.
+
long twist = 0
+
Initializes the twist property of the PointerEvent object.
+
DOMString pointerType = ""
+
Initializes the pointerType property of the PointerEvent object.
+
boolean isPrimary = false
+
Initializes the isPrimary property of the PointerEvent object.
+
+

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 [[!DOM-LEVEL-3-EVENTS]]. The steps for constructing an event are defined in [[!DOM4]]. See the examples for sample code demonstrating how to fire an untrusted pointer event.

+
The PointerEvent interface inherits from MouseEvent, defined in [[DOM-LEVEL-3-EVENTS]] and extended by [[CSSOM-VIEW]].
+
+
+

Button States

+
+

Chorded Button Interactions

+

Some pointer devices, such as mouse or pen, support multiple buttons. In the [[!DOM-LEVEL-3-EVENTS]] Mouse Event model, each button press produces a mousedown and mouseup event. To better abstract this hardware difference and simplify cross-device input authoring, Pointer Events do not fire overlapping pointerdown and pointerup events for chorded button presses (depressing an additional button while another button on the pointer device is already depressed).

+

Instead, chorded button presses can be detected by inspecting changes to the button and buttons properties. The button and buttons properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] MouseEvent interface, but with a change in semantics and values, as outlined in the following sections.

+
The modifications to the button and buttons properties apply only to pointer events. For any compatibility mouse events the value of button and buttons should follow [[!DOM-LEVEL-3-EVENTS]].
+
+
+

The button property

+

To identify button state transitions in any pointer event (and not just pointerdown and pointerup), the button property indicates the device button whose state-change fired the event.

- - - + - - - + + + + + + +
Pointer Device TypepointerType Value
Device Button Changesbutton
Mousemouse
Pen Styluspen
Touch Contacttouch
Neither buttons nor touch/pen contact changed since last event-1
Left Mouse,
Touch Contact,
Pen contact (with no modifier buttons pressed)		0
Middle Mouse1
Right Mouse,
Pen contact with barrel button pressed		2
X1 (back) Mouse3
X2 (forward) Mouse4
Pen contact with eraser button pressed5
-

If the device type cannot be detected by the user agent, then the value MUST be an empty string. If a user agent supports pointer device types other than those listed above, the value of pointerType SHOULD be vendor prefixed to avoid conflicting names for different types of devices. Future specifications MAY provide additional normative values for other device types.

-
- See Example 2 for a basic demonstration of how the pointerType can be used. Also note that developers should include some form of default handling to cover user agents that may have implemented their own custom pointerType values and for situations where pointerType is simply an empty string. -
-
-
readonly attribute boolean isPrimary
-
- Indicates if the pointer represents the primary pointer of this pointer type. -
-
-
-
long pointerId = 0
-
Initializes the pointerId property of the PointerEvent object.
-
double width = 1
-
Initializes the width property of the PointerEvent object.
-
double height = 1
-
Initializes the height property of the PointerEvent object.
-
float pressure = 0
-
Initializes the pressure property of the PointerEvent object.
-
long tiltX = 0
-
Initializes the tiltX property of the PointerEvent object.
-
long tiltY = 0
-
Initializes the tiltY property of the PointerEvent object.
-
long twist = 0
-
Initializes the twist property of the PointerEvent object.
-
DOMString pointerType = ""
-
Initializes the pointerType property of the PointerEvent object.
-
boolean isPrimary = false
-
Initializes the isPrimary property of the PointerEvent object.
-
-
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 [[!DOM-LEVEL-3-EVENTS]]. The steps for constructing an event are defined in [[!DOM4]]. See the examples for sample code demonstrating how to fire an untrusted pointer event.
-
The PointerEvent interface inherits from MouseEvent, defined in [[DOM-LEVEL-3-EVENTS]] and extended by [[CSSOM-VIEW]].
-
-
-

Button States

-
-

Chorded Button Interactions

-

Some pointer devices, such as mouse or pen, support multiple buttons. In the [[!DOM-LEVEL-3-EVENTS]] Mouse Event model, each button press produces a mousedown and mouseup event. To better abstract this hardware difference and simplify cross-device input authoring, Pointer Events do not fire overlapping pointerdown and pointerup events for chorded button presses (depressing an additional button while another button on the pointer device is already depressed).

-

Instead, chorded button presses can be detected by inspecting changes to the button and buttons properties. The button and buttons properties are inherited from the [[!DOM-LEVEL-3-EVENTS]] MouseEvent interface, but with a change in semantics and values, as outlined in the following sections.

-
The modifications to the button and buttons properties apply only to pointer events. For any compatibility mouse events the value of button and buttons should follow [[!DOM-LEVEL-3-EVENTS]].
-
-
-

The button property

-

To identify button state transitions in any pointer event (and not just pointerdown and pointerup), the button property indicates the device button whose state-change fired the event.

- - - - - - - - - - - -
Device Button Changesbutton
Neither buttons nor touch/pen contact changed since last event-1
Left Mouse,
Touch Contact,
Pen contact (with no modifier buttons pressed)		0
Middle Mouse1
Right Mouse,
Pen contact with barrel button pressed		2
X1 (back) Mouse3
X2 (forward) Mouse4
Pen contact with eraser button pressed5
-
During a mouse drag, the value of the button property in a pointermove event will be different from that in a mousemove event. For example, while moving the mouse with the right button pressed, the pontermove events will have the button value -1, but the mousemove events will have the button value 2.
+
During a mouse drag, the value of the button property in a pointermove event will be different from that in a mousemove event. For example, while moving the mouse with the right button pressed, the pontermove events will have the button value -1, but the mousemove events will have the button value 2.
+
+
+

The buttons property

+

The buttons property gives the current state of the device buttons as a bitmask (same as in MouseEvent, but with an expanded set of possible values).

+ + + + + + + + + + + +
Current state of device buttonsbuttons
Mouse move with no buttons pressed0
Left Mouse,
Touch Contact,
Pen contact (with no modifier buttons pressed)		1
Middle Mouse4
Right Mouse,
Pen contact with barrel button pressed		2
X1 (back) Mouse8
X2 (forward) Mouse16
Pen contact with eraser button pressed32
+
-

The buttons property

-

The buttons property gives the current state of the device buttons as a bitmask (same as in MouseEvent, but with an expanded set of possible values).

- - - - - - - - - - - -
Current state of device buttonsbuttons
Mouse move with no buttons pressed0
Left Mouse,
Touch Contact,
Pen contact (with no modifier buttons pressed)		1
Middle Mouse4
Right Mouse,
Pen contact with barrel button pressed		2
X1 (back) Mouse8
X2 (forward) Mouse16
Pen contact with eraser button pressed32
+

The Primary Pointer

+

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.
    • +
+
Authors who desire single-pointer interaction can achieve this by ignoring non-primary pointers (however, see the note below on multiple primary pointers).
+
When two or more pointer device types are being used concurrently, multiple pointers (one for each pointerType) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.
+
In some cases, it is possible for the user agent to fire pointer events in which no pointer is marked as a primary pointer. For instance, when there are multiple active pointers of a particular type like multi-touch and the primary pointer is removed (e.g. it leaves the screen), there will be no primary pointer events. Also on the platforms where the primary pointer is determined using all active pointers on the device (including those targeted at an application other than the user agent), if the first touch interaction is targeted outside the user agent and a secondary (multi-touch) touch interaction is targeted inside the user agent, then the user agent may fire pointer events for the second contact with a value of false for isPrimary.
+
Current operating systems and user agents don't usually have a concept of multiple mouse inputs. When more than one mouse device is present (for instance, on a laptop with both a trackpad and an external mouse), all mouse devices are generally treated as a single device - movements on any of the devices are translated to movement of a single mouse pointer, and there is no distinction between button presses on different mouse devices. For this reason, there will usually only be a single mouse pointer, and that pointer will be primary.
+
-

The Primary Pointer

-

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.
    • -
-
Authors who desire single-pointer interaction can achieve this by ignoring non-primary pointers (however, see the note below on multiple primary pointers).

-
When two or more pointer device types are being used concurrently, multiple pointers (one for each pointerType) are considered primary. For example, a touch contact and a mouse cursor moved simultaneously will produce pointers that are both considered primary.
-
In some cases, it is possible for the user agent to fire pointer events in which no pointer is marked as a primary pointer. For instance, when there are multiple active pointers of a particular type like multi-touch and the primary pointer is removed (e.g. it leaves the screen), there will be no primary pointer events. Also on the platforms where the primary pointer is determined using all active pointers on the device (including those targeted at an application other than the user agent), if the first touch interaction is targeted outside the user agent and a secondary (multi-touch) touch interaction is targeted inside the user agent, then the user agent may fire pointer events for the second contact with a value of false for isPrimary.
-
Current operating systems and user agents don't usually have a concept of multiple mouse inputs. When more than one mouse device is present (for instance, on a laptop with both a trackpad and an external mouse), all mouse devices are generally treated as a single device - movements on any of the devices are translated to movement of a single mouse pointer, and there is no distinction between button presses on different mouse devices. For this reason, there will usually only be a single mouse pointer, and that pointer will be primary.
-
-
-
-

Pointer Event Types

-
+

Pointer Event Types

Firing events using the PointerEvent interface

-

To fire a pointer event name e means to fire an event named e as defined in [[!DOM4]] with an event using the PointerEvent interface whose attributes are set as defined in PointerEvent Interface.

+

To fire a pointer event name e means to fire an event named e as defined in [[!DOM4]] with an event using the PointerEvent interface whose attributes are set as defined in PointerEvent Interface.

-

Initialize the bubbles attribute for the event to true if the event name is -

    -
  • pointerdown
    • -
  • pointerup
    • -
  • pointercancel
    • -
  • pointermove
    • -
  • pointerover
    • -
  • pointerout
    • -
  • gotpointercapture
    • -
  • lostpointercapture
    • -
-

-

Initialize the cancelable attribute for the event to true if the event name is -

    -
  • pointerdown
    • -
  • pointerup
    • -
  • pointermove
    • -
  • pointerover
    • -
  • pointerout
    • -
-

+

Initialize the bubbles attribute for the event to true if the event name is

+
    +
  • pointerdown
    • +
  • pointerup
    • +
  • pointercancel
    • +
  • pointermove
    • +
  • pointerover
    • +
  • pointerout
    • +
  • gotpointercapture
    • +
  • lostpointercapture
    • +
+

Initialize the cancelable attribute for the event to true if the event name is

+

    +
  • pointerdown
    • +
  • pointerup
    • +
  • pointermove
    • +
  • pointerover
    • +
  • pointerout
    • +

The target object at which the event is fired is determined as follows:

-
-

List of Pointer Events

-

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

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Event TypeSync/AsyncBubblesCancelableDefault Action
pointeroverSyncYesYesNone
pointerenterSyncNoNoNone
pointerdownSyncYesYesVaries: when the pointer is primary, all default actions of the mousedown event -
Canceling this event also sets the PREVENT MOUSE EVENT flag for this pointerType, which prevents subsequent firing of certain compatibility mouse events.
pointermoveSyncYesYesVaries: when the pointer is primary, all default actions of mousemove
pointerupSyncYesYesVaries: when the pointer is primary, all default actions of mouseup
pointercancelSyncYesNoNone
pointeroutSyncYesYesNone
pointerleaveSyncNoNoNone
gotpointercaptureSync/AsyncYesNoNone
lostpointercaptureSync/AsyncYesNoNone
-

In the case of the primary pointer, these events (with the exception of gotpointercapture, and lostpointercapture) may also fire compatibility mouse events.

-
-
-

The pointerover event

-
A user agent MUST fire a pointer event named pointerover when a pointing device is moved into the hit test boundaries of an element. A user agent MUST also fire this event prior to firing a pointerdown event for devices that do not support hover (see pointerdown).
-
-
-

The pointerenter event

-
A user agent MUST fire a pointer event named pointerenter when a pointing device is moved into the hit test boundaries of an element or one of its descendants, including as a result of a pointerdown event from a device that does not support hover (see pointerdown). This event type is similar to pointerover, but differs in that it does not bubble.
-
There are similarities between this event type, the mouseenter event described in [[DOM-LEVEL-3-EVENTS]], and the CSS :hover pseudo-class described in [[CSS21]]. See also the pointerleave event.
-
-
-

The pointerdown event

-

A 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 stylus makes physical contact with the digitizer.

-
For mouse (or other multi-button pointer devices), this means 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, a user agent MUST also fire a pointer event named pointerover followed by a pointer event named pointerenter prior to dispatching the pointerdown event.

-
Authors can prevent the firing of certain compatibility mouse events by canceling the 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 pointermove event

-
A user agent MUST fire a pointer event named pointermove when a pointer changes coordinates. Additionally, when a pointer changes button state, pressure, tilt, twist, or contact geometry (e.g. width and height) and the circumstances produce no other pointer events defined in this specification then a user agent MUST fire a pointer event named pointermove.
-
-
-

The pointerup event

-
A 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 physical contact with the digitizer. -

For input devices that do not support hover, a user agent MUST also fire a pointer event named pointerout followed by a pointer event named pointerleave after dispatching the pointerup event.

-
-
For mouse (or other multi-button pointer devices), this means pointerdown and pointerup are not fired for all of the same circumstances as mousedown and mouseup. See chorded buttons for more information.
-
-
-

The pointercancel event

-
A user agent MUST fire a pointer event named pointercancel in the following circumstances: +
+

List of Pointer Events

+

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

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Event TypeSync/AsyncBubblesCancelableDefault Action
pointeroverSyncYesYesNone
pointerenterSyncNoNoNone
pointerdownSyncYesYesVaries: when the pointer is primary, all default actions of the mousedown event +
Canceling this event also sets the PREVENT MOUSE EVENT flag for this pointerType, which prevents subsequent firing of certain compatibility mouse events.
pointermoveSyncYesYesVaries: when the pointer is primary, all default actions of mousemove
pointerupSyncYesYesVaries: when the pointer is primary, all default actions of mouseup
pointercancelSyncYesNoNone
pointeroutSyncYesYesNone
pointerleaveSyncNoNoNone
gotpointercaptureSync/AsyncYesNoNone
lostpointercaptureSync/AsyncYesNoNone
+

In the case of the primary pointer, these events (with the exception of gotpointercapture, and lostpointercapture) may also fire compatibility mouse events.

+
+
+

The pointerover event

+

A user agent MUST fire a pointer event named pointerover when a pointing device is moved into the hit test boundaries of an element. A user agent MUST also fire this event prior to firing a pointerdown event for devices that do not support hover (see pointerdown).

+
+
+

The pointerenter event

+

A user agent MUST fire a pointer event named pointerenter when a pointing device is moved into the hit test boundaries of an element or one of its descendants, including as a result of a pointerdown event from a device that does not support hover (see pointerdown). This event type is similar to pointerover, but differs in that it does not bubble.

+
There are similarities between this event type, the mouseenter event described in [[DOM-LEVEL-3-EVENTS]], and the CSS :hover pseudo-class described in [[CSS21]]. See also the pointerleave event.
+
+
+

The pointerdown event

+

A 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 stylus makes physical contact with the digitizer.

+
For mouse (or other multi-button pointer devices), this means 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, a user agent MUST also fire a pointer event named pointerover followed by a pointer event named pointerenter prior to dispatching the pointerdown event.

+
Authors can prevent the firing of certain compatibility mouse events by canceling the 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 pointermove event

+

A user agent MUST fire a pointer event named pointermove when a pointer changes coordinates. Additionally, when a pointer changes button state, pressure, tilt, twist, or contact geometry (e.g. width and height) and the circumstances produce no other pointer events defined in this specification then a user agent MUST fire a pointer event named pointermove.

+
+
+

The pointerup event

+

A 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 physical contact with the digitizer.

+

For input devices that do not support hover, a user agent MUST also fire a pointer event named pointerout followed by a pointer event named pointerleave after dispatching the pointerup event.

+
For mouse (or other multi-button pointer devices), this means pointerdown and pointerup are not fired for all of the same circumstances as mousedown and mouseup. See chorded buttons for more information.
+
+
+

The pointercancel event

+

A user agent MUST fire a pointer event named pointercancel in the following circumstances:

  • The user agent has determined that a pointer is unlikely to continue to produce events (for example, because of a hardware event).
  • After having fired the pointerdown event, if the pointer is subsequently used to manipulate the page viewport (e.g. panning or zooming).

After firing the pointercancel event, a user agent MUST also fire a pointer event named pointerout followed by firing a pointer event named pointerleave.

-

This section is non-normative.

+

This section is non-normative.

Examples of scenarios in which a user agent might determine that a pointer is unlikely to continue to produce events include:

  • A device's screen orientation is changed while a pointer is active.
    • @@ -565,157 +562,165 @@

    The pointercancel event

Methods for changing the device's screen orientation, recognizing accidental input, or using a pointer to manipulate the viewport (e.g. panning or zooming) are out of scope for this specification.

-
-
-
-

The pointerout event

-
A user agent MUST fire a pointer event named pointerout when any of the following occurs: +
+
+

The pointerout event

+

A user agent MUST fire a pointer event named pointerout when any of the following occurs:

  • A pointing device is moved out of the hit test boundaries of an element.
  • After firing the pointerup event for a device that does not support hover (see pointerup).
  • After firing the pointercancel event (see pointercancel).
  • When a pen stylus leaves the hover range detectable by the digitizer.
- -
-
-

The pointerleave event

-
A user agent MUST fire a pointer event named pointerleave when a pointing device is moved out of the hit test boundaries of an element and all of its descendants, including as a result of a pointerup and pointercancel events from a device that does not support hover (see pointerup and pointercancel). User agents MUST also fire a pointer event named pointerleave when a pen stylus leaves hover range detectable by the digitizer. This event type is similar to pointerout, but differs in that it does not bubble and that it MUST not be fired until the pointing device has left the boundaries of the element and the boundaries of all of its descendants.
-
There are similarities between this event type, the mouseleave event described in [[DOM-LEVEL-3-EVENTS]], and the CSS :hover pseudo-class described in [[CSS21]]. See also the pointerenter event.
-
-
-

The gotpointercapture event

-
A 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 lostpointercapture event

-
A 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. Subsequent events for the pointer 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 pointerleave event

+

A user agent MUST fire a pointer event named pointerleave when a pointing device is moved out of the hit test boundaries of an element and all of its descendants, including as a result of a pointerup and pointercancel events from a device that does not support hover (see pointerup and pointercancel). User agents MUST also fire a pointer event named pointerleave when a pen stylus leaves hover range detectable by the digitizer. This event type is similar to pointerout, but differs in that it does not bubble and that it MUST not be fired until the pointing device has left the boundaries of the element and the boundaries of all of its descendants.

+
There are similarities between this event type, the mouseleave event described in [[DOM-LEVEL-3-EVENTS]], and the CSS :hover pseudo-class described in [[CSS21]]. See also the pointerenter event.
+
+
+

The gotpointercapture event

+

A 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 lostpointercapture event

+

A 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. Subsequent events for the pointer 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.

+
- - -
-

Extensions to the Element interface

-

The following section describes extensions to the existing Element interface, defined in [[!HTML5]], to facilitate the setting and releasing of pointer capture.

-
-
-
attribute EventHandler ongotpointercapture
-
- The event handler IDL attribute (see [[!HTML5]]) for the gotpointercapture event type. -
-
attribute EventHandler onlostpointercapture
-
- The event handler IDL attribute (see [[!HTML5]]) for the lostpointercapture event type. -
-
void setPointerCapture(long pointerId)
-
-

Sets pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked. Subsequent events for the pointer 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. Throws a DOMException with the name InvalidPointerId when the provided method's argument does not match any of the active pointers.

-
See Pointer Capture.
-
-
void releasePointerCapture(long pointerId)
-
-

Releases pointer capture for the pointer identified by the argument pointerId from 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. Throws a DOMException with the name InvalidPointerId when the provided the method's argument does not match any of the active pointers.

-
See Pointer Capture.
-
-
-
-
-

Extensions to the GlobalEventHandlers interface

-

The following section describes extensions to the existing GlobalEventHandlers interface, defined in [[!HTML5]], to facilitate the event handler registration.

-
- -
attribute EventHandler onpointerdown
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerdown event type. -
-
attribute EventHandler onpointermove
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointermove event type. -
-
attribute EventHandler onpointerup
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerup event type. -
-
attribute EventHandler onpointercancel
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointercancel event type. -
-
attribute EventHandler onpointerover
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerover event type. -
-
attribute EventHandler onpointerout
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerout event type. -
-
attribute EventHandler onpointerenter
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerenter event type. -
-
attribute EventHandler onpointerleave
-
- The event handler IDL attribute (see [[!HTML5]]) for the pointerleave event type. -
-
- -
- -
-

Extensions to the Navigator interface

-
-

The Navigator interface is defined in [[!HTML5]]. This specification extends the Navigator interface to provide device detection support.

-
-
readonly attribute long maxTouchPoints
-

The maximum number of simultaneous touch contacts supported by the device. In the case of devices with multiple digitizers (e.g. multiple touchscreens), the value MUST be the maximum of the set of maximum supported contacts by each individual digitizer.

-

For example, suppose a device has 3 touchscreens, which support 2, 5, and 10 simultaneous touch contacts, respectively. The value of maxTouchPoints should be 10.

-
-
-
While a maxTouchPoints value of greater than 0 indicates the user's device is capable of supporting touch input, it does not necessarily mean the user will use touch input. Authors should be careful to also consider other input modalities that could be present on the system, such as mouse, pen, screen readers, etc.
-
maxTouchPoints is often used to ensure that the interaction model of the content can be recognized by the current hardware. UI affordances can be provided to users with less capable hardware. On platforms where the precise number of touch points is not known, the minimum number guaranteed to be recognized is provided. Therefore, it is possible for the number of recognized touch points to exceed the value of maxTouchPoints.
-
-
-
-

Declaring candidate regions for default touch behaviors

-

For touch input, the default action of any and all pointer events MUST NOT be a manipulation of the viewport (e.g. panning or zooming).

-
Touch manipulations are intentionally not a default action of pointer events. Removing this dependency on the cancellation of events facilitates performance optimizations by the user agent.
+
+ +
+

Extensions to the Element interface

+
+

The following section describes extensions to the existing Element interface, defined in [[!HTML5]], to facilitate the setting and releasing of pointer capture.

+
+
attribute EventHandler ongotpointercapture
+
+ The event handler IDL attribute (see [[!HTML5]]) for the gotpointercapture event type. +
+
attribute EventHandler onlostpointercapture
+
+ The event handler IDL attribute (see [[!HTML5]]) for the lostpointercapture event type. +
+
void setPointerCapture(long pointerId)
+
+

Sets pointer capture for the pointer identified by the argument pointerId to the element on which this method is invoked. Subsequent events for the pointer 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. Throws a DOMException with the name InvalidPointerId when the provided method's argument does not match any of the active pointers.

+
See Pointer Capture.
+
+
void releasePointerCapture(long pointerId)
+
+

Releases pointer capture for the pointer identified by the argument pointerId from 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. Throws a DOMException with the name InvalidPointerId when the provided the method's argument does not match any of the active pointers.

+
See Pointer Capture.
+
+
+
+
+
+

Extensions to the GlobalEventHandlers interface

+
+

The following section describes extensions to the existing GlobalEventHandlers interface, defined in [[!HTML5]], to facilitate the event handler registration.

+
+
attribute EventHandler onpointerdown
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerdown event type. +
+
attribute EventHandler onpointermove
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointermove event type. +
+
attribute EventHandler onpointerup
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerup event type. +
+
attribute EventHandler onpointercancel
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointercancel event type. +
+
attribute EventHandler onpointerover
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerover event type. +
+
attribute EventHandler onpointerout
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerout event type. +
+
attribute EventHandler onpointerenter
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerenter event type. +
+
attribute EventHandler onpointerleave
+
+ The event handler IDL attribute (see [[!HTML5]]) for the pointerleave event type. +
+
+
+
+
-

The touch-action CSS property

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

Extensions to the Navigator interface

+

The Navigator interface is defined in [[!HTML5]]. This specification extends the Navigator interface to provide device detection support.

+
+
readonly attribute long maxTouchPoints
+

The maximum number of simultaneous touch contacts supported by the device. In the case of devices with multiple digitizers (e.g. multiple touchscreens), the value MUST be the maximum of the set of maximum supported contacts by each individual digitizer.

+

For example, suppose a device has 3 touchscreens, which support 2, 5, and 10 simultaneous touch contacts, respectively. The value of maxTouchPoints should be 10.

+
+
+
While a maxTouchPoints value of greater than 0 indicates the user's device is capable of supporting touch input, it does not necessarily mean the user will use touch input. Authors should be careful to also consider other input modalities that could be present on the system, such as mouse, pen, screen readers, etc.
+
maxTouchPoints is often used to ensure that the interaction model of the content can be recognized by the current hardware. UI affordances can be provided to users with less capable hardware. On platforms where the precise number of touch points is not known, the minimum number guaranteed to be recognized is provided. Therefore, it is possible for the number of recognized touch points to exceed the value of maxTouchPoints.
+
+
+
+

Declaring candidate regions for default touch behaviors

+

For touch input, the default action of any and all pointer events MUST NOT be a manipulation of the viewport (e.g. panning or zooming).

+
Touch manipulations are intentionally not a default action of pointer events. Removing this dependency on the cancellation of events facilitates performance optimizations by the user agent.
+
+

The touch-action CSS property

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

The touch-action CSS property determines whether touch input MAY trigger default behavior supplied by user agent. This includes, but is not limited to, behaviors such as panning or zooming.

-

When a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. A touch behavior is supported if allowed by the touch-action properties of all elements between the hit tested element and it's nearest ancestor with the default touch behavior (including both the hit tested element and the element with the default touch behavior).

+

When a user touches an element, the effect of that touch is determined by the value of the touch-action property and the default touch behaviors on the element and its ancestors. A touch behavior is supported if allowed by the touch-action properties of all elements between the hit tested element and it's nearest ancestor with the default touch behavior (including both the hit tested element and the element with the default touch behavior).

-
Some user agents support touch actions triggered by interactions of multiple concurrent pointers (e.g. multi-touch). Methods for processing or associating the touch-action values of multiple concurrent pointers is out of scope for this specification.
-

During the execution of a user agent touch behavior, the user agent MUST NOT fire subsequent pointer events for the pointer. The user agent MUST fire a pointer event named pointercancel (and subsequently a pointerout event and one or more pointerleave events) whenever all of the following are true, in order to end the stream of events for the pointer:

-
    -
  • The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior,
    • -
  • a pointerdown event has been sent for the pointer, and
    • -
  • a pointerup or pointercancel event (following the above mentioned pointerdown) has not yet been sent for the pointer.
    • -
+
Some user agents support touch actions triggered by interactions of multiple concurrent pointers (e.g. multi-touch). Methods for processing or associating the touch-action values of multiple concurrent pointers is out of scope for this specification.
+

During the execution of a user agent touch behavior, the user agent MUST NOT fire subsequent pointer events for the pointer. The user agent MUST fire a pointer event named pointercancel (and subsequently a pointerout event and one or more pointerleave events) whenever all of the following are true, in order to end the stream of events for the pointer:

+
    +
  • The user agent has determined (via methods out of scope for this specification) that touch input is to be consumed for a touch behavior,
    • +
  • a pointerdown event has been sent for the pointer, and
    • +
  • a pointerup or pointercancel event (following the above mentioned pointerdown) has not yet been sent for the pointer.
    • +
-
Once a touch action has been started, and the user agent has already determined whether or not the action should be handled as a user agent touch behavior, any changes to the relevant touch-action value will be ignored for the duration of the touch action. For instance, programmatically changing the touch-action value for an element from auto to none as part of a pointerdown handler script will not result in the user agent aborting or suppressing any default touch behavior for that touch for as long as that pointer is active.
+
Once a touch action has been started, and the user agent has already determined whether or not the action should be handled as a user agent touch behavior, any changes to the relevant touch-action value will be ignored for the duration of the touch action. For instance, programmatically changing the touch-action value for an element from auto to none as part of a pointerdown handler script will not result in the user agent aborting or suppressing any default touch behavior for that touch for as long as that pointer is active.

Values have the following meanings:

-
auto
The user agent MAY determine any permitted touch behaviors, such as panning and zooming manipulations of the viewport, for touches that begin on the element.
-
none
Touches that begin on the element MUST NOT trigger default touch behaviors.
-
pan-x
pan-left
pan-right
pan-y
pan-up
pan-down

The user agent MAY consider touches that begin on the element only for the purposes of scrolling that starts in any of the directions specified by all of the listed values. Once scrolling is started, the direction may be reversed by the user even if scrolls that start in the reversed direction are disallowed. In contrast, when scrolling is restricted to starting along a single axis (eg. pan-y), the axis cannot be changed during the scroll.

-

In the case of pan-left, pan-right, pan-up and pan-down, the direction is interpreted as the opposite of the physical movement in the screen co-ordinate space. For example, pan-up always corresponds to input event sequences where typically (ignoring situations such as iframe containers with CSS rotation transforms) screenY is increasing (i.e. an interaction where the user moves a touch point down the screen).

-
manipulation
The user agent MAY consider touches that begin on the element only for the purposes of scrolling and continuous zooming. Any additional behaviors supported by auto are out of scope for this specification.
+
auto
+
The user agent MAY determine any permitted touch behaviors, such as panning and zooming manipulations of the viewport, for touches that begin on the element.
+
none
+
Touches that begin on the element MUST NOT trigger default touch behaviors.
+
pan-x
pan-left
pan-right
pan-y
pan-up
pan-down
+
+

The user agent MAY consider touches that begin on the element only for the purposes of scrolling that starts in any of the directions specified by all of the listed values. Once scrolling is started, the direction may be reversed by the user even if scrolls that start in the reversed direction are disallowed. In contrast, when scrolling is restricted to starting along a single axis (eg. pan-y), the axis cannot be changed during the scroll.

+

In the case of pan-left, pan-right, pan-up and pan-down, the direction is interpreted as the opposite of the physical movement in the screen co-ordinate space. For example, pan-up always corresponds to input event sequences where typically (ignoring situations such as iframe containers with CSS rotation transforms) screenY is increasing (i.e. an interaction where the user moves a touch point down the screen).

+
manipulation
+
The user agent MAY consider touches that begin on the element only for the purposes of scrolling and continuous zooming. Any additional behaviors supported by auto are out of scope for this specification.
-
The terms "pan" and "scroll" are considered synonymous. Defining an interaction or gesture for triggering panning or scrolling, or for triggering behavior for the auto or none values are out of scope for this specification.
-
The 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 touch actions. For elements not supported by default, such as <span> which is a non-replaced inline element (see [[HTML5]]), 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 overscroll behavior. 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 scrolls 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 scrolling 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 pan operation beyond it's extent can scroll the document within the viewport if possible. It's not possible to change the behavior of a pan in the middle of an operation.

-
Disabling some default touch behaviors may allow user agents to respond to other behaviors more quickly. For example, with 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.
+
The terms "pan" and "scroll" are considered synonymous. Defining an interaction or gesture for triggering panning or scrolling, or for triggering behavior for the auto or none values are out of scope for this specification.
+
The 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 touch actions. For elements not supported by default, such as <span> which is a non-replaced inline element (see [[HTML5]]), 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 overscroll behavior. 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 scrolls 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 scrolling 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 pan operation beyond it's extent can scroll the document within the viewport if possible. It's not possible to change the behavior of a pan in the middle of an operation.

+
+
Disabling some default touch behaviors may allow user agents to respond to other behaviors more quickly. For example, with 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 touches.
@@ -757,69 +762,62 @@ 
The touch-action CSS property

     </div>
 </div>
-
-
-
-

Pointer Capture

-
-

- 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 [[HTML5]] <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.

-
- Custom Volume Slider -
Example of a custom slider control that chooses a value by sliding the thumb element back and forth. After 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.
-
-
- -
-

Setting Pointer Capture

- Pointer capture is set on an element by calling the element.setPointerCapture(pointerId) method. When this method is invoked, a user agent MUST run the following steps: -
    -
  1. If the pointerId provided as the method's argument does not match any of the active pointers, then throw a DOMException with the name InvalidPointerId.
    2. -
  2. If the Element on which this method is invoked does not participate in its ownerDocument's tree, throw an exception with the name InvalidStateError.
    3. -
  3. If the pointer is not in the active buttons state, then terminate these steps.
    4. -
  4. For the specified pointerId, set the pending pointer capture target override to the Element on which this method was invoked.
    5. -
-
When pointer capture is set, pointerover, pointerout, pointerenter, and pointerleave events are only generated when crossing the boundary of the element that has capture as other elements can no longer be targeted by the pointer. This has the effect of suppressing these events on all other elements.
-
+
+

Pointer Capture

+

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 [[HTML5]] <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.

+
+ Custom Volume Slider +
Example of a custom slider control that chooses a value by sliding the thumb element back and forth. After 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.
+
-
-

Releasing Pointer Capture

- Pointer capture is released on an element explicitly by calling the element.releasePointerCapture(pointerId) method. When this method is called, a user agent MUST run the following steps: -
    -
  1. If the pointerId provided 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 DOMException with the name InvalidPointerId.
    2. -
  2. If pointer capture is not currently set for the specified pointer, then terminate these steps.
    3. -
  3. If the pointer capture target override for the specified pointerId is not the Element on which this method was invoked, then terminate these steps.
    4. -
  4. For the specified pointerId, clear the pending pointer capture target override, if set.
    5. -
-
-
-

Implicit Pointer Capture

-
Some user agents implement their own implicit pointer capture behavior - for instance, for touch interactions, a user agent could automatically capture the pointer as part of an interaction on a form control (such as a button) to improve user interaction (allowing some finger movement to stray outside of the form control itself during the interaction). As part of this behavior, user agents typically fire gotpointercapture and lostpointercapture events, even though no explicit pointer capture functions (setPointerCapture and releasePointerCapture) were called.
-

Implicit Release of Pointer Capture

-

Immediately after firing the pointerup or pointercancel events, a user agent MUST run the steps as if the releasePointerCapture() method has been called with an argument equal to the pointerId property of the pointerup or pointercancel event just dispatched.

-

When the pointer capture target override is removed from its ownerDocument's tree, clear the pending pointer capture target override and pointer capture target override nodes and fire a PointerEvent named lostpointercapture at the document.

+

Setting Pointer Capture

+

Pointer capture is set on an element by calling the element.setPointerCapture(pointerId) method. When this method is invoked, a user agent MUST run the following steps:

+
    +
  1. If the pointerId provided as the method's argument does not match any of the active pointers, then throw a DOMException with the name InvalidPointerId.
    2. +
  2. If the Element on which this method is invoked does not participate in its ownerDocument's tree, throw an exception with the name InvalidStateError.
    3. +
  3. If the pointer is not in the active buttons state, then terminate these steps.
    4. +
  4. For the specified pointerId, set the pending pointer capture target override to the Element on which this method was invoked.
    5. +
+
When pointer capture is set, pointerover, pointerout, pointerenter, and pointerleave events are only generated when crossing the boundary of the element that has capture as other elements can no longer be targeted by the pointer. This has the effect of suppressing these events on all other elements.
+
+ +
+

Releasing Pointer Capture

+

Pointer capture is released on an element explicitly by calling the element.releasePointerCapture(pointerId) method. When this method is called, a user agent MUST run the following steps:

+
    +
  1. If the pointerId provided 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 DOMException with the name InvalidPointerId.
    2. +
  2. If pointer capture is not currently set for the specified pointer, then terminate these steps.
    3. +
  3. If the pointer capture target override for the specified pointerId is not the Element on which this method was invoked, then terminate these steps.
    4. +
  4. For the specified pointerId, clear the pending pointer capture target override, if set.
    5. +
+
+
+

Implicit Pointer Capture

+
Some user agents implement their own implicit pointer capture behavior - for instance, for touch interactions, a user agent could automatically capture the pointer as part of an interaction on a form control (such as a button) to improve user interaction (allowing some finger movement to stray outside of the form control itself during the interaction). As part of this behavior, user agents typically fire gotpointercapture and lostpointercapture events, even though no explicit pointer capture functions (setPointerCapture and releasePointerCapture) were called.
+
+

Implicit Release of Pointer Capture

+

Immediately after firing the pointerup or pointercancel events, a user agent MUST run the steps as if the releasePointerCapture() method has been called with an argument equal to the pointerId property of the pointerup or pointercancel event just dispatched.

+

When the pointer capture target override is removed from its ownerDocument's tree, clear the pending pointer capture target override and pointer capture target override nodes and fire a PointerEvent named lostpointercapture at the document.

+
-
-
+

Compatibility Mapping with Mouse Events

-

The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how a user agent MAY map generic pointer input to mouse events for compatibility with this content.

+

The vast majority of web content existing today codes only to Mouse Events. The following describes an algorithm for how a user agent MAY map generic pointer input to mouse events for compatibility with this content.

The compatibility mapping with mouse events are an OPTIONAL feature of this specification. User agents are encouraged to support the feature for best compatibility with existing legacy content. User agents that do not support compatibility mouse events are still encouraged to support the click and contextmenu events (see the note below).

-
+

The click event, defined in [[DOM-LEVEL-3-EVENTS]], and the contextmenu event, defined in [[HTML5]], are not considered compatibility mouse events as they are typically tied to user interface activation and are fired from other input devices, like keyboards.

In user agents that support firing click and/or contextmenu, calling preventDefault during a pointer event typically does not have an effect on whether click and/or contextmenu are fired or not. Because they are not compatibility mouse events, user agents typically fire click and contextmenu for all pointing devices, including pointers that are not primary pointers.

The relative ordering of these high-level events (click, contextmenu, focus, blur, etc.) with pointer events is undefined and varies between user agents. For example, in some user agents contextmenu will often follow a pointerup, in others it'll often precede a pointerup or pointercancel, and in some situations it may be fired without any corresponding pointer event (such as a keyboard shortcut).

-
+

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. And, the mouseover, mouseout, mouseenter, and mouseleave events are never prevented (even if the pointer is down).
- +
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. And, the mouseover, mouseout, mouseenter, and mouseleave events are never prevented (even if the pointer is down).

Tracking the effective position of the legacy mouse pointer

-

While only the primary pointers can produce compatibility mouse events, multiple primary pointers can be active simultaneously, each producing its own compatibility mouse events. Since all these compatibility events would appear to MouseEvent code to be coming from a single mouse device, user agents are encouraged to guarantee that the compatibility mouse events are consistent from a single device perspective. For mouse transition events (i.e., mouseover, mouseout, mouseenter and mouseleave), this means the entry/exit state for every event target is valid as implied by [[!DOM-LEVEL-3-EVENTS]]. Users 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:

    @@ -828,128 +826,120 @@

    Tracking the effective position of the legacy mouse pointer

  1. Dispatch mouseover, mouseout, mouseenter and mouseleave events as per [[!DOM-LEVEL-3-EVENTS]] 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.
  2. Set effective legacy mouse pointer position to T.
-

Mapping for devices that support hover

-
Whenever a user agent is to dispatch a pointer event for a device that supports hover, it SHOULD run the following steps: -
    -
  1. If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
    2. -
  2. If the pointer event to be is dispatched is pointerdown, pointerup or pointermove, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
    3. -
  3. Dispatch the pointer event.
    4. -
  4. If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType.
    5. -
  5. If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: -
      -
    • pointerdown, then fire a mousedown event.
      • -
    • pointermove, then fire a mousemove event.
      • -
    • pointerup, then fire a mouseup event.
      • -
    • pointercancel, then fire a mouseup event at the window.
      • -
    -
    6. -
  6. If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.
    7. -
-
+

Whenever a user agent is to dispatch a pointer event for a device that supports hover, it SHOULD run the following steps:

+
    +
  1. If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
    2. +
  2. If the pointer event to be is dispatched is pointerdown, pointerup or pointermove, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
    3. +
  3. Dispatch the pointer event.
    4. +
  4. If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType.
    5. +
  5. If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: +
      +
    • pointerdown, then fire a mousedown event.
      • +
    • pointermove, then fire a mousemove event.
      • +
    • pointerup, then fire a mouseup event.
      • +
    • pointercancel, then fire a mouseup event at the window.
      • +
    +
    6. +
  6. If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.
    7. +

Mapping for devices that do not support hover

-
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: +

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 mousemove event on an element before clicking it.
-
Hover is sometimes used to toggle the visibility of UI elements in content designed for mouse (e.g. "hover menus"). This content is often incompatible with devices that do not support hover. This specification does not define a mapping or behavior for compatibility with this scenario. It will be considered in a future version of the specification. -
- This requires that user agents provide a different mapping for these types of input devices. Whenever a user agent is to dispatch a pointer event for a device that does not support hover, it SHOULD run the following steps: -
    -
  1. If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
    2. -
  2. If the pointer event to be dispatched is pointerover and the pointerdown event has not yet been dispatched for this pointer, then fire a mousemove event (for compatibility with legacy mouse-specific code).
    3. -
  3. If the pointer event to be is dispatched is pointerdown, pointerup or pointermove, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
    4. -
  4. Dispatch the pointer event.
    5. -
  5. If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType.
    6. -
  6. If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: -
      -
    • pointerdown, then fire a mousedown event.
      • -
    • pointermove, then fire a mousemove event.
      • -
    • pointerup, then fire a mouseup event.
      • -
    • pointercancel, then fire a mouseup event at the window.
      • -
    -
    7. -
  7. If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.
    8. +
    Hover is sometimes used to toggle the visibility of UI elements in content designed for mouse (e.g. "hover menus"). This content is often incompatible with devices that do not support hover. This specification does not define a mapping or behavior for compatibility with this scenario. It will be considered in a future version of the specification.
    +

    This requires that user agents provide a different mapping for these types of input devices. Whenever a user agent is to dispatch a pointer event for a device that does not support hover, it SHOULD run the following steps:

    +
      +
    1. If the isPrimary property for the pointer event to be dispatched is false then dispatch the pointer event and terminate these steps.
      2. +
    2. If the pointer event to be dispatched is pointerover and the pointerdown event has not yet been dispatched for this pointer, then fire a mousemove event (for compatibility with legacy mouse-specific code).
      3. +
    3. If the pointer event to be is dispatched is pointerdown, pointerup or pointermove, dispatch compatibility mouse transition events as described in Tracking the effective position of the legacy mouse pointer.
      4. +
    4. Dispatch the pointer event.
      5. +
    5. If the pointer event dispatched was pointerdown and the event was canceled, then set the PREVENT MOUSE EVENT flag for this pointerType.
      6. +
    6. If the PREVENT MOUSE EVENT flag is not set for this pointerType and the pointer event dispatched was: +
        +
      • pointerdown, then fire a mousedown event.
        • +
      • pointermove, then fire a mousemove event.
        • +
      • pointerup, then fire a mouseup event.
        • +
      • pointercancel, then fire a mouseup event at the window.
        • +
      +
      7. +
    7. If the pointer event dispatched was pointerup or pointercancel, clear the PREVENT MOUSE EVENT flag for this pointerType.
      8. +
    +
    +

    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:

    +
      +
    1. mousemove
      2. +
    2. pointerover
      3. +
    3. mouseover
      4. +
    4. pointerenter
      5. +
    5. mouseenter
      6. +
    6. pointerdown
      7. +
    7. mousedown
      8. +
    8. Zero or more pointermove and mousemove events, depending on movement of the pointer
      9. +
    9. pointerup
      10. +
    10. mouseup
      11. +
    11. click
      12. +
    12. pointerout
      13. +
    13. mouseout
      14. +
    14. pointerleave
      15. +
    15. mouseleave
    +

    If, however, the pointerdown event is canceled during this interaction then the sequence of events would be:

    +
      +
    1. mousemove
      2. +
    2. pointerover
      3. +
    3. mouseover
      4. +
    4. pointerenter
      5. +
    5. mouseenter
      6. +
    6. pointerdown
      7. +
    7. Zero or more pointermove events, depending on movement of the pointer
      8. +
    8. pointerup
      9. +
    9. click
      10. +
    10. pointerout
      11. +
    11. mouseout
      12. +
    12. pointerleave
      13. +
    13. mouseleave
      14. +
    -
    -

    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:

    -
      -
    1. mousemove
      2. -
    2. pointerover
      3. -
    3. mouseover
      4. -
    4. pointerenter
      5. -
    5. mouseenter
      6. -
    6. pointerdown
      7. -
    7. mousedown
      8. -
    8. Zero or more pointermove and mousemove events, depending on movement of the pointer
      9. -
    9. pointerup
      10. -
    10. mouseup
      11. -
    11. click
      12. -
    12. pointerout
      13. -
    13. mouseout
      14. -
    14. pointerleave
      15. -
    15. mouseleave
      16. -
    -

    If, however, the pointerdown event is canceled during this interaction then the sequence of events would be: -

      -
    1. mousemove
      2. -
    2. pointerover
      3. -
    3. mouseover
      4. -
    4. pointerenter
      5. -
    5. mouseenter
      6. -
    6. pointerdown
      7. -
    7. Zero or more pointermove events, depending on movement of the pointer
      8. -
    8. pointerup
      9. -
    9. click
      10. -
    10. pointerout
      11. -
    11. mouseout
      12. -
    12. pointerleave
      13. -
    13. mouseleave
      14. -
    -
-
-

Acknowledgments

-

- 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 - group members: - Arthur Barstow, - Matt Brubeck, - Rick Byers, - Cathy Chan, - Scott González, - Patrick H. Lauke, - Sangwhan Moon, - Olli Pettay, - Jacob Rossi, - Doug Schepers and - Asir Vedamuthu. -

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

+
+

Acknowledgments

+

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 group members: + Arthur Barstow, + Matt Brubeck, + Rick Byers, + Cathy Chan, + Scott González, + Patrick H. Lauke, + Sangwhan Moon, + Olli Pettay, + Jacob Rossi, + Doug Schepers and + Asir Vedamuthu. +

+

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.

-
+

Revision History

The following is an informative summary of substantial and major editorial changes between publications of this specification, relative to the first [[PointerEvents]] specification. See the complete revision history of the Editor's Drafts of this specification.

Changes since the 24 February 2015 Recommendation