├── .pr-preview.json
├── CODE_OF_CONDUCT.md
├── README.md
├── images
├── altitudeAngle.png
├── azimuthAngle.png
└── sources
│ ├── altitude-azimuth.afdesign
│ ├── altitude-azimuth.skp
│ └── azimuth-altitude.png
├── index.html
└── w3c.json
/.pr-preview.json:
--------------------------------------------------------------------------------
1 | {
2 | "src_file": "index.html",
3 | "type": "respec"
4 | }
5 |
--------------------------------------------------------------------------------
/CODE_OF_CONDUCT.md:
--------------------------------------------------------------------------------
1 | # Code of Conduct
2 |
3 | All documentation, code and communication under this repository are covered by the [W3C Code of Ethics and Professional Conduct](https://www.w3.org/Consortium/cepc/).
4 |
--------------------------------------------------------------------------------
/README.md:
--------------------------------------------------------------------------------
1 | Touch Events
2 | ============
3 |
4 | This is the document repository for the [Touch Events Community Group](http://www.w3.org/community/touchevents/).
5 |
6 | **This Community Group is now closed, and the last version of the specification that the group worked on has been mirrored to: [Final Community Group Report for Touch Events Level 2](https://www.w3.org/community/reports/touchevents/CG-FINAL-touch-events-20240704/)**.
7 |
8 | There is currently no intention to carry on further work on the Touch Events specification. This document has been maintained up to this point to reflect additions and changes made in user agents since the release of the original [Touch Events Level 1](https://www.w3.org/TR/touch-events/) specification. The Community Group considers Touch Events a _legacy API_ – authors are strongly encouraged to adopt [Pointer Events](https://www.w3.org/TR/pointerevents/) instead.
9 |
10 | # Branches
11 |
12 | This repo has two branches of note:
13 |
14 | * `gh-pages` - this branch is active; it contains the [Touch Events Level 2](http://w3c.github.io/touch-events/) editors draft, which includes all the changes from an old `v1-errata` branch and the [Touch Events Extension Working Group Note](http://www.w3.org/TR/touch-events-extensions/))
15 | * `v1` - this branch is it not active, and only contains the working branch for the v1 specification
16 |
17 | # Process for Landing Changes
18 |
19 | Per the group's [2015-Jan-27 agreement](http://www.w3.org/2015/01/27-touchevents-minutes.html#item05), the following process was used to review and approve Pull Requests:
20 |
21 | * Submit a pull request and post the PR's link to the [public-touchevents](https://lists.w3.org/Archives/Public/public-touchevents/) e-mail list asking for feedback.
22 | * As soon as one of the listed spec editors approves the PR it can be merged.
23 | * If there's debate over a PR that has already landed, it may be reverted until consensus is reached.
24 |
25 | ## Tests
26 |
27 | For normative changes, a corresponding
28 | [web-platform-tests](https://github.com/web-platform-tests/wpt) PR is highly appreciated. Typically,
29 | both PRs will be merged at the same time. Note that a test change that contradicts the spec should
30 | not be merged before the corresponding spec change. If testing is not practical, please explain why
31 | and if appropriate [file an issue](https://github.com/web-platform-tests/wpt/issues/new) to follow
32 | up later. Add the `type:untestable` or `type:missing-coverage` label as appropriate.
33 |
--------------------------------------------------------------------------------
/images/altitudeAngle.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c/touch-events/163ad3168058ce786ad3ce65dc09f76c4ff381a3/images/altitudeAngle.png
--------------------------------------------------------------------------------
/images/azimuthAngle.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c/touch-events/163ad3168058ce786ad3ce65dc09f76c4ff381a3/images/azimuthAngle.png
--------------------------------------------------------------------------------
/images/sources/altitude-azimuth.afdesign:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c/touch-events/163ad3168058ce786ad3ce65dc09f76c4ff381a3/images/sources/altitude-azimuth.afdesign
--------------------------------------------------------------------------------
/images/sources/altitude-azimuth.skp:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c/touch-events/163ad3168058ce786ad3ce65dc09f76c4ff381a3/images/sources/altitude-azimuth.skp
--------------------------------------------------------------------------------
/images/sources/azimuth-altitude.png:
--------------------------------------------------------------------------------
https://raw.githubusercontent.com/w3c/touch-events/163ad3168058ce786ad3ce65dc09f76c4ff381a3/images/sources/azimuth-altitude.png
--------------------------------------------------------------------------------
/index.html:
--------------------------------------------------------------------------------
1 |
2 |
3 |
4 | Touch Events - Level 2
5 |
6 |
11 |
12 |
14 |
105 |
137 |
148 |
149 |
150 |
151 |
This specification was published by the Touch Events Community Group. It is not a W3C Standard nor is it on the W3C Standards Track.
This version of the specification includes fixes and improvements to Touch Events Level 1, and incorporates the features previously published as Touch Event Extensions.
154 |
There is currently no intention to carry on further work on the Touch Events specification. This document has been maintained up to this point to reflect additions and changes made in user agents since the release of the original Touch Events Level 1 specification. The Community Group considers Touch Events a legacy API – authors are strongly encouraged to adopt Pointer Events instead.
155 |
156 |
157 |
The Touch Events specification defines a set of low-level events that represent one or more points of contact with a touch-sensitive surface, and changes of those points with respect to the surface and any DOM elements displayed upon it (e.g. for touch screens) or associated with it (e.g. for drawing tablets without displays). It also addresses pen-tablet devices, such as drawing tablets, with consideration toward stylus capabilities.
158 |
159 |
160 |
Introduction
161 |
User Agents that run on terminals which provide touch input to use web applications typically use interpreted mouse events to allow users to access interactive web applications. However, these interpreted events, being normalized data based on the physical touch input, tend to have limitations on delivering the intended user experience. Additionally, it is not possible to handle concurrent input regardless of device capability, due to constraints of mouse events: both system level limitations and legacy compatibility.
162 |
Meanwhile, native applications are capable of handling both cases with the provided system APIs.
163 |
The Touch Events specification provides a solution to this problem by specifying interfaces to allow web applications to directly handle touch events, and multiple touch points for capable devices.
164 |
165 |
166 |
This specification defines conformance criteria that apply to a single product: the user agent that implements the interfaces that it contains.
167 |
WindowProxy is defined in [[!HTML5]].
168 |
WebIDL Conformance
169 |
The IDL blocks in this specification are conforming IDL fragments as defined by the WebIDL specification [[!WEBIDL]].
170 |
A conforming user agent must also be a conforming JavaScript implementation of this IDL fragments in this specification, with the following exception:
171 |
172 |
173 | section 4.4.6 of Web IDL requires that IDL attributes are reflected as accessor properties on interface prototype objects. Instead of this, the user agent may reflect IDL attributes as data properties on the platform objects that implement the relevant interface. These data properties must have the same behavior when getting and setting as would be exhibited when invoking the getter and setter of the accessor properties on the platform object.
174 |
175 |
176 |
Note: Both ways of reflecting IDL attributes allow for simply getting and setting the property on the platform object to work. For example, given a Touch object aTouch, evaluating aTouch.target would return the EventTarget for the Touch object. If the user agent implements IDL attributes as accessor properties, then the property access invokes the getter which returns the EventTarget. If the user agent implements IDL attributes as data properties on the platform object with the same behavior as would be found with the accessor properties, then the object would appear to have an own property named target whose value is an EventTarget object, and the property access would return this value.
177 |
178 |
179 |
Touch Interface
180 |
This interface describes an individual touch point for a touch event. Touch objects are immutable; after one is created, its attributes must not change.
When a touch point becomes active, it must be assigned an identifier that is distinct from any other active touch point. While the touch point remains active, all events that refer to it must assign it the same identifier.
230 |
231 |
target
232 |
233 |
The EventTarget on which the touch point started when it was first placed on the surface, even if the touch point has since moved outside the interactive area of that element.
234 |
Some implementations alter the target element to correct for the imprecision of coarse input. Therefore, the target element may not necessarily be the element directly at the coordinates of the event. The methods used to target/disambiguate coarse input are out of scope for this specification.
235 |
236 |
screenX
237 |
238 |
The horizontal coordinate of point relative to the screen in pixels
239 |
240 |
screenY
241 |
242 |
The vertical coordinate of point relative to the screen in pixels
243 |
244 |
clientX
245 |
246 |
The horizontal coordinate of point relative to the viewport in pixels, excluding any scroll offset
247 |
248 |
clientY
249 |
250 |
The vertical coordinate of point relative to the viewport in pixels, excluding any scroll offset
251 |
252 |
pageX
253 |
254 |
The horizontal coordinate of point relative to the viewport in pixels, including any scroll offset
255 |
256 |
pageY
257 |
258 |
The vertical coordinate of point relative to the viewport in pixels, including any scroll offset
259 |
260 |
radiusX
261 |
262 |
The radius of the ellipse which most closely circumscribes the touching area (e.g. finger, stylus) along the axis indicated by rotationAngle, in CSS pixels (as defined by [[!CSS-VALUES]]) of the same scale as screenX; 0 if no value is known. The value must not be negative.
263 |
264 |
radiusY
265 |
266 |
The radius of the ellipse which most closely circumscribes the touching area (e.g. finger, stylus) along the axis perpendicular to that indicated by rotationAngle, in CSS pixels (as defined by [[!CSS-VALUES]]) of the same scale as screenY; 0 if no value is known. The value must not be negative.
267 |
268 |
rotationAngle
269 |
270 |
The angle (in degrees) that the ellipse described by radiusX and radiusY is rotated clockwise about its center; 0 if no value is known. The value must be greater than or equal to 0 and less than 90.
271 |
If the ellipse described by radiusX and radiusY is circular, then rotationAngle has no effect. The user agent may use 0 as the value in this case, or it may use any other value in the allowed range. (For example, the user agent may use the rotationAngle value from the previous touch event, to avoid sudden changes.)
272 |
273 |
force
274 |
275 |
A relative value of pressure applied, in the range 0 to 1, where 0 is no pressure, and 1 is the highest level of pressure the touch device is capable of sensing; 0 if no value is known. In environments where force is known, the absolute pressure represented by the force attribute, and the sensitivity in levels of pressure, may vary.
276 |
277 |
altitudeAngle
278 |
279 |
The altitude (in radians) of the transducer (e.g. pen/stylus), in the range [0,π/2] — where 0 is parallel to the surface (X-Y plane), and π/2 is perpendicular to the surface. For hardware and platforms that do not report tilt or angle, the value MUST be 0.
280 |
281 | The default value defined here for altitudeAngle is 0. This differs from the Pointer Events - Level 3 [[POINTEREVENTS]] specification's definition for the altitudeAngle property, which has a default value of π/2, which positions the transducer as being perpendicular to the surface.
282 |
283 |
284 |
285 |
286 | Example altitudeAngle of π/4 (45 degrees from the X-Y plane).
287 |
288 |
289 |
290 |
azimuthAngle
291 |
292 |
The azimuth angle (in radians) of the transducer (e.g. pen/stylus), in the range [0, 2π] — where 0 represents a transducer whose cap is pointing in the direction of increasing X values (point to "3 o'clock" if looking straight down) on the X-Y plane, and the values progressively increase when going clockwise (π/2 at "6 o'clock", π at "9 o'clock", 3π/2 at "12 o'clock"). When the transducer is perfectly perpendicular to the surface (altitudeAngle of π/2), the value MUST be 0. For hardware and platforms that do not report tilt or angle, the value MUST be 0.
293 |
294 |
295 |
296 | Example azimuthAngle of π/6 ("4 o'clock").
297 |
298 |
299 |
300 |
touchType
301 |
302 |
The type of device used to trigger the touch.
303 |
304 |
305 |
306 |
TouchType
307 |
308 |
An enumeration representing the different types of possible touch input.
309 |
310 |
311 |
312 |
direct
313 |
314 |
A direct touch from a finger on the screen.
315 |
316 |
stylus
317 |
318 |
A touch from a stylus or pen device.
319 |
320 |
321 |
322 |
323 |
TouchList Interface
324 |
This interface defines a list of individual points of contact for a touch event. TouchList objects are immutable; after one is created, its contents must not change.
325 |
A TouchList object's supported property indices ([[!WEBIDL]]) are the numbers in the range 0 to one less than the length of the list.
Returns the Touch at the specified index in the list or null if the index is not less than the length of the list.
341 |
342 |
343 |
344 |
345 |
TouchEvent Interface
346 |
This interface defines the touchstart, touchend, touchmove, and touchcancel event types. TouchEvent objects are immutable; after one is created and initialized, its attributes must not change. TouchEvent inherits from the UIEvent interface defined in [[!DOM-LEVEL-3-EVENTS]].
347 |
The TouchEventInit dictionary is used by the TouchEvent interface's constructor to provide a mechanism by which to construct untrusted (synthetic) touch events. It inherits from the EventModifierInit dictionary defined in [[!DOM-LEVEL-3-EVENTS]]. The steps for constructing an event are defined in [[!DOM4]]. See the example for sample code demonstrating how to fire an untrusted touch event.
A list of Touch objects for every point of contact currently touching the surface.
372 |
373 |
targetTouches
374 |
375 |
A list of Touch objects for every point of contact that is touching the surface and started on the element that is the target of the current event.
376 |
377 |
changedTouches
378 |
379 |
A list of Touch objects for every point of contact which contributed to the event.
380 |
For the touchstart event this must be a list of the touch points that just became active with the current event. For the touchmove event this must be a list of the touch points that have moved since the last event. For the touchend and touchcancel events this must be a list of the touch points that have just been removed from the surface, with the last known coordinates of the touch points before they were removed.
381 |
382 |
altKey
383 |
384 |
true if the alt (Alternate) key modifier is activated; otherwise false
385 |
386 |
metaKey
387 |
388 |
true if the meta (Meta) key modifier is activated; otherwise false. On some platforms this attribute may map to a differently-named key modifier.
389 |
390 |
ctrlKey
391 |
392 |
true if the ctrl (Control) key modifier is activated; otherwise false
393 |
394 |
shiftKey
395 |
396 |
true if the shift (Shift) key modifier is activated; otherwise false
397 |
398 |
getModifierState(keyArg)
399 |
400 |
Queries the state of a modifier using a key value. Returns true if it is a modifier key and the modifier is activated, false otherwise.
401 |
402 |
403 |
404 |
TouchEvent Implementer's Note
405 |
406 |
User agents should ensure that all Touch objects available from a given TouchEvent are all associated to the same document that the TouchEvent was dispatched to. To implement this, user agents should maintain a notion of the current touch-active document. On first touch, this is set to the target document where the touch was created. When all active touch points are released, the touch-active document is cleared. All TouchEvents are dispatched to the current touch-active document, and each Touch object it contains refers only to DOM elements (and co-ordinates) in that document. If a touch starts entirely outside the currently touch-active document, then it is ignored entirely.
407 |
408 |
409 |
410 |
Usage Examples
411 |
The examples below demonstrate the relations between the different TouchList members defined in a TouchEvent.
This example demonstrates the utility and relations between the touches and targetTouches members defined in the TouchEvent interface. The following code will generate different output based on the number of touch points on the touchable element and the document:
415 |
416 | <div id="touchable">This element is touchable.</div>
417 |
418 | <script>
419 | document.getElementById('touchable').addEventListener('touchstart', function(ev) {
420 |
421 | if (ev.touches.item(0) == ev.targetTouches.item(0))
422 | {
423 | /**
424 | * If the first touch on the surface is also targeting the
425 | * "touchable" element, the code below should execute.
426 | * Since targetTouches is a subset of touches which covers the
427 | * entire surface, TouchEvent.touches >= TouchEvents.targetTouches
428 | * is always true.
429 | */
430 |
431 | document.write('Hello Touch Events!');
432 | }
433 |
434 | if (ev.touches.length == ev.targetTouches.length)
435 | {
436 | /**
437 | * If all of the active touch points are on the "touchable"
438 | * element, the length properties should be the same.
439 | */
440 |
441 | document.write('All points are on target element')
442 | }
443 |
444 | if (ev.touches.length > 1)
445 | {
446 | /**
447 | * On a single touch input device, there can only be one point
448 | * of contact on the surface, so the following code can only
449 | * execute when the terminal supports multiple touches.
450 | */
451 |
452 | document.write('Hello Multiple Touch!');
453 | }
454 |
455 | }, false);
456 | </script>
457 |
This example demonstrates the utility of changedTouches and it's relation with the other TouchList members of the TouchEvent interface. The code is a example which triggers whenever a touch point is removed from the defined touchable element:
462 |
463 | <div id="touchable">This element is touchable.</div>
464 |
465 | <script>
466 | document.getElementById('touchable').addEventListener('touchend', function(ev) {
467 |
468 | /**
469 | * Example output when three touch points are on the surface,
470 | * two of them being on the "touchable" element and one point
471 | * in the "touchable" element is lifted from the surface:
472 | *
473 | * Touch points removed: 1
474 | * Touch points left on element: 1
475 | * Touch points left on document: 2
476 | */
477 |
478 | document.write('Touch points removed: ' + ev.changedTouches.length);
479 | document.write('Touch points left on element: ' + ev.targetTouches.length);
480 | document.write('Touch points left on document: ' + ev.touches.length);
481 |
482 | }, false);
483 | </script>
484 |
The following table provides a summary of the TouchEvent event types defined in this specification. All events should accomplish the bubbling phase. All events should be composed [[WHATWG-DOM]] events.
Canceling a touch event can prevent or otherwise interrupt scrolling (which could be happening in parallel with script execution). For maximum scroll performance, a user agent may not wait for each touch event associated with the scroll to be processed to see if it will be canceled. In such cases the user agent should generate touch events whose cancelable property is false, indicating that preventDefault cannot be used to prevent or interrupt scrolling. Otherwise cancelable will be true.
A user agent must dispatch this event type to indicate when the user places a touch point on the touch surface.
615 |
The target of this event must be an Element. If the touch point is within a frame, the event should be dispatched to an element in the child browsing context of that frame.
616 |
If this event is canceled, it should prevent any default actions caused by any touch events associated with the same active touch point, including mouse events or scrolling.
617 |
618 |
619 |
The touchend event
620 |
A user agent must dispatch this event type to indicate when the user removes a touch point from the touch surface, also including cases where the touch point physically leaves the touch surface, such as being dragged off of the screen.
621 |
The target of this event must be the same Element on which the touch point started when it was first placed on the surface, even if the touch point has since moved outside the interactive area of the target element.
A user agent must dispatch this event type to indicate when the user moves a touch point along the touch surface.
628 |
The target of this event must be the same Element on which the touch point started when it was first placed on the surface, even if the touch point has since moved outside the interactive area of the target element.
629 |
Note that the rate at which the user agent sends touchmove events is implementation-defined, and may depend on hardware capabilities and other implementation details.
630 |
A user agent should suppress the default action caused by any touchmove event until at least one touchmove event associated with the same active touch point is not canceled. Whether the default action is suppressed for touchmove events after at least one touchmove event associated with the same active touch point is not canceled is implementation dependent.
631 |
632 |
633 |
The touchcancel event
634 |
A user agent must dispatch this event type to indicate when a touch point has been disrupted in an implementation-specific manner, such as a synchronous event or action originating from the UA canceling the touch, or the touch point leaving the document window into a non-document area which is capable of handling user interactions (e.g. the UA's native user interface, or an area of the document which is managed by a plug-in). A user agent may also dispatch this event type when the user places more touch points on the touch surface than the device or implementation is configured to store, in which case the earliest Touch object in the TouchList should be removed.
635 |
The target of this event must be the same Element on which the touch point started when it was first placed on the surface, even if the touch point has since moved outside the interactive area of the target element.
Set touch's target to the result of invoking retargetingtouch's unadjustedTarget against touchEvent's target.
651 |
652 |
653 |
654 |
655 |
656 |
657 |
Conditionally exposing legacy touch event APIs
658 |
User agents have an associated boolean expose legacy touch event APIs whose value is implementation-defined.
659 |
Existing web content often use the existence of these APIs as a signal that the user agent is a touch-enabled "mobile" device, and therefore exposing these APIs on non-mobile devices, even if they are touch-enabled, could lead to a suboptimal user experience for such web content.
660 |
661 |
662 |
Extensions to the GlobalEventHandlers mixin
663 |
The following section describes extensions to the existing GlobalEventHandlers mixin, defined in [[!HTML5]], to facilitate the event handler registration. For user agents where expose legacy touch event APIs is false, this mixin must not be implemented.
The event handler IDL attribute (see [[!HTML5]]) for the touchstart event type.
676 |
677 |
ontouchend
678 |
679 |
The event handler IDL attribute (see [[!HTML5]]) for the touchend event type.
680 |
681 |
ontouchmove
682 |
683 |
The event handler IDL attribute (see [[!HTML5]]) for the touchmove event type.
684 |
685 |
ontouchcancel
686 |
687 |
The event handler IDL attribute (see [[!HTML5]]) for the touchcancel event type.
688 |
689 |
690 |
691 |
692 |
Interaction with Mouse Events and click
693 |
The user agent may dispatch both touch events and (for compatibility with web content not designed for touch) mouse events [[!DOM-LEVEL-2-EVENTS]] in response to the same user input. If the user agent dispatches both touch events and mouse events in response to a single user action, then the touchstart event type must be dispatched before any mouse event types for that action. If touchstart, touchmove, or touchend are canceled, the user agent should not dispatch any mouse event that would be a consequential result of the prevented touch event.
694 |
If a Web application can process touch events, it can cancel the events, and no corresponding mouse events would need to be dispatched by the user agent. If the Web application is not specifically written for touch input devices, it will react to the subsequent mouse events instead.
695 |
User agents will typically dispatch mouse and click events only for single-finger activation gestures (like tap and long press). Gestures involving movement of the touch point or multi-touch interactions – with two or more active touch points – will usually only generate touch events.
696 |
If the user agent interprets a sequence of touch events as a tap gesture, then it should dispatch mousemove, mousedown, mouseup, and click events (in that order) at the location of the touchend event for the corresponding touch input. If the contents of the document have changed during processing of the touch events, then the user agent may dispatch the mouse events to a different target than the touch events.
697 |
The default actions and ordering of any further touch and mouse events are implementation-defined, except as specified elsewhere.
698 |
699 |
The activation of an element (e.g., in some implementations, a tap) would typically produce the following event sequence (though this may vary slightly, depending on specific user agent behavior):
700 |
701 |
touchstart
702 |
Zero or more touchmove events, depending on movement of the finger
703 |
touchend
704 |
mousemove (for compatibility with legacy mouse-specific code)
705 |
mousedown
706 |
mouseup
707 |
click
708 |
709 |
If, however, either the touchstart, touchmove or touchend event has been canceled during this interaction, no mouse or click events will be fired, and the resulting sequence of events would simply be:
710 |
711 |
touchstart
712 |
Zero or more touchmove events, depending on movement of the finger
713 |
touchend
714 |
715 |
716 |
717 |
Even if a user agent supports Touch Events, this does not necessarily mean that a touchscreen is the only input mechanism available to users. Particularly in the case of touch-enabled laptops, or traditional "touch only" devices (such as phones and tablets) with paired external input devices, users may use the touchscreen in conjunction with a trackpad, mouse or keyboard. For this reason, developers should avoid binding event listeners with "either touch or mouse/keyboard" conditional code, as this results in sites/application that become touch-exclusive, preventing users from being able to use any other input mechanism.
718 |
719 | // conditional "touch OR mouse/keyboard" event binding
720 | // DON'T DO THIS, as it makes interactions touch-exclusive
721 | // on devices that have both touch and mouse/keyboard
722 |
723 | if ('ontouchstart' in window) {
724 | // set up event listeners for touch
725 | target.addEventListener('touchend', ...);
726 | ...
727 | } else {
728 | // set up event listeners for mouse/keyboard
729 | target.addEventListener('click', ...);
730 | ...
731 | }
732 |
733 |
Instead, developers should handle different forms of input concurrently.
734 |
735 | // concurrent "touch AND mouse/keyboard" event binding
736 |
737 | // set up event listeners for touch
738 | target.addEventListener('touchend', function(e) {
739 | // prevent compatibility mouse events and click
740 | e.preventDefault();
741 | ...
742 | });
743 | ...
744 |
745 | // set up event listeners for mouse/keyboard
746 | target.addEventListener('click', ...);
747 | ...
748 |
749 |
To avoid processing the same interaction twice for touch (once for the touch event, and once for the compatibility mouse events), developers should make sure to cancel the touch event, suppressing the generation of any further mouse or click events. Alternatively, see the InputDeviceCapabilities API for a way to detect mouse events that were generated as a result of touch events.
750 |
751 |
752 |
753 |
Glossary
754 |
755 |
active touch point
756 |
757 | A touch point which is currently on the screen and is being tracked by the user agent. The touch point becomes active when the user agent first dispatches a touchstart event indicating its appearance. It ceases to be active after the user agent dispatches a touchend or touchcancel event indicating that the touch point is removed from the surface or no longer tracked.
758 |
759 |
touch point
760 |
The coordinate point at which a pointer (e.g finger or stylus) intersects the target surface of an interface. This may apply to a finger touching a touch-screen, or an digital pen writing on a piece of paper.
761 |
canceled event
762 |
An event whose default action was prevented by means of preventDefault(), returning false in an event handler, or other means as defined by [[!DOM-LEVEL-3-EVENTS]] and [[!HTML5]].
763 |
764 |
765 |
766 |
Acknowledgements
767 |
Many thanks to the WebKit engineers for developing the model used as a basis for this spec, Neil Roberts (SitePen) for his summary of WebKit touch events, Peter-Paul Koch (PPK) for his write-ups and suggestions, Robin Berjon for developing the ReSpec.js spec authoring tool, and the WebEvents WG for their many contributions.
768 |
Many others have made additional comments as the spec developed, which have led to steady improvements. Among them are Matthew Schinckel, Andrew Grieve, Cathy Chan, Boris Zbarsky, Patrick H. Lauke, and Simon Pieters. If we inadvertently omitted your name, please let me know.
769 |
The group acknowledges the following contributors to this specification's test suite: Matt Brubeck, Olli Pettay, Art Barstow, Cathy Chan and Rick Byers.
285 | 
295 |