PointerEvents/UseCasesAndRequirements

This document defines Use Cases (UC) and requirements (Reqs) for specifications being developed by the Pointer Events Working Group.

This document is non-normative i.e. informative and, at the moment, should be considered a Living Document that continues to evolve.

Comments on this document are welcome and should be submitted to public-pointer-events@w3.org.

Terminology

This document uses the following terms:

• Pointer - a physical input device such as a stylus, mouse, pen or touchscreen (possibly activated by a user's finger).

• Touch Point - a point of contact; the place where a Pointer contacts (e.g. touches) an application.

• Pointer Event - an abstract DOM Event created when the user applies a Pointer to an application. There is a one-to-one correspondence between a Touch Point and a Pointer Event.

General Use Cases

Use Case #1 - Image Application

An image application presents several images in a stack. The application allows the end user to directly manipulate the images e.g. to rotate, regardless of the user's Pointer.

Use Case #2 - Mapping Application

A mapping application provides a map pane that is constructed by tiling data from a map server. The user pans and zooms the (document) element containing the tiled map with the rest of the screen staying intact. The user's interaction can be via any type of Pointer.

Requirements: Pointer Events v1 Specification

The Pointer Events v1 specification has the following requirements:

• Regardless of the Pointer, a single Pointer Event event is created for each Touch Point.

• Each Pointer Event must include the following data to the application, if applicable for the Pointer:
  • A unique identification number
  • Width and height geometry of the Touch Point
  • A normalized measure of the touch point's pressure
  • The X and Y tilt axis of the touch point

• A Pointer Event must indicate the Pointer's type (e.g. pen, touchscreen) or indicate the type is not known (if the type cannot be determined).

• Each Pointer Event must include a timestamp to facilitate application semantics for "simultaneous" Pointer Events i.e. multi-touch.

• A Pointer Event must identify any modifier keys that are active when the Pointer Event is created.

• The "action" resulting from a Pointer Event, must be application agnostic. (For example, the specification must not prescribe an application's semantics for a Pointer Event.)

• Adding a new Pointer (device) must not break an application that does not support the new Pointer.

• An application must be able to determine the target element for each Touch Point.

• Define the following event type pairs, depending on the status and state of the Pointer: up and down; over and out; enter and leave; and capture and release.

• Define the following unary event types: cancel and move.

• Define event handler API for each event type.

• Define an API to determine if Pointer Events are supported.

• Define an API to determine the maximum number of Touch Points supported by the application's device.

• Define a declarative mechanism (e.g. CSS) an application can use to override the UA's default touch action for specific elements.

• The specification must define a mechanism to re-target a Pointer Event to another element.

Requirements: Pointer Events v.Next Specification

• Support raw trackpad data; (for more information see Bug 20218).

• Support Pointers with varying levels of pressure; (for more information see 4-Dec-2012 discussion).

• Support Pointers with fully spherical tilt and no digitizer plane (e.g. "air pens")

• Support other modalities such as Voice input.

• Define compatibility mapping/behavior for sites that hide content behind hover (mouseover/out or CSS :hover). For more information see Bug 20222 and a related discussion thread.

• Support Brush-type stylus. For more information see e-mails from: Brandon Wallace 26-Sep-2012, Pierre Saslawsky 21-Dec-2012 and Jacob Rossi 24-Dec-2012

• pointerType extensibility. Rick Byers 9-February-2013. Group agreed on 12-March-2013 to consider this in v.Next. See also the related 3D Pointers e-mail thread by Bill Fisher 15-March-2013.
• Add rotation attribute to PointerEvent. Mose Bottacini 1-March-2013. Group agreed on 12-March-2013 to consider this in v.Next.

• buttons attribute bitmask is painful. Alex Russell 12-February-2013. Group agreed on 12-March-2013 to consider this in v.Next.

• navigator.maxTouchPoints is deeply touch-specific. Alex Russell 12-February-2013. Group agreed on 12-March-2013 to consider this in v.Next.

• Expose a list of pointers for better multi-pointer handling. See comment from Konstantinov Sergey on 22-March-2013

• How to accommodate test assertions 5.4 to 5.7? Today, these test assertions cannot be tested using the current test harness and cannot be run manually. We are awaiting harness improvements (or WebDriver). Group agreed on 04-March-2014 to consider this in v.Next.

• Pull-to-refresh experiences (native touch scrolling in one direction on an axis, scripted scrolling or other behavior in the other direction on that same axis)
• "Hidey Bars", or more generally, scripted behaviors triggered by the start, progress, or completion of a touch action OR when a pointer is removed from the screen during the execution of a touch action.
• Programmatic access to the native scrolling curve (e.g. an API to define a curve that maps user input to scrolling output).
• API for requesting high-frequency movement position data. See http://lists.w3.org/Archives/Public/public-pointer-events/2014AprJun/0055.html