W3C home > Mailing lists > Public > public-pointer-events@w3.org > October to December 2012

touchevent / pointerevent compatibility mapping

From: Rick Byers <rbyers@google.com>
Date: Thu, 22 Nov 2012 12:10:47 -0500
Message-ID: <CAFUtAY-LbbTD+Q9n56bNLN=2aDY+gRRJcoq0dwEuzCMTRTmH9g@mail.gmail.com>
To: public-pointer-events@w3.org
I believe we agreed in our first call that one of the main things we
needed to add to the pointer events spec is a definition of
compatibility mapping with touch events (for browsers that support
them).  I've done a bit of thinking about this and suggest the
following as a starting point for discussion.

High level goal: code designed for one type of events is not generally
broken by the availability of support for or use of the other type.  A
library consuming touch events and a library consuming pointer events
can work properly together in the same application - to the same
extent that two different libraries both consuming pointer event or
touch events can.  In particular, when they are operating on different
parts of the DOM, they should be completely transparent to each other.
 This property is important for scenarios like sites that have an
embedded map from another site (with our without the use of iframes).
The map may be designed for touch events, and should continue to work
even though the embedding site is using pointer events.  Similarly,
the map application should be free to opt-in to consuming only pointer
events where supported without much risk of breaking embedding sites
which are consuming touch events.

To achieve this (more or less), I think we can follow the same basic
model used for mouse event compatibility mapping, with some
modifications (eg. not only for isPrimary).  It'll take a bit of
wordsmithing to describe how this merges with the algorithm in section
7.2, but the basic idea is to do the following before dispatching any
mouse events:
1. if pointerType is not POINTER_TYPE_TOUCH, skip all of this and
continue as normal
2. if the pointer event dispatched was pointerdown and the event was
cancelled, set the PREVENT TOUCH EVENT flag for this pointer ID
3. if the PREVENT TOUCH EVENT flag isn't set for this pointer ID, then:
  - for pointerdown, dispatch touchstart
  - for pointermove, dispatch touchmove
  - for pointerup, dispatch touchup
  - for pointercancel, dispatch touchcancel
  The TouchEvent has a changedTouches with exactly one Touch element,
initialized as appropriate with all the values from this PointerEvent.
 In particular, TouchEvent.identifier is computed from
PointerEvent.pointerId using any 1:1 mapping.
4. If isPrimary is true, touchstart was dispatched, and the event was
cancelled, set the PREVENT MOUSE EVENT flag
5. if the pointer event dispatched was pointerup or pointercancel,
clear the PREVENT TOUCH EVENT flag for this pointer ID

Once concern here is that the mouse event compatibility model impacts
how UAs will generate fake mouse events for touch input.  The touch
events standard specifies that mousedown/mouseup/click are generated
after a touchend.  In this model, the sequence of events for a tap
gesture (excluding any move/over/out) would be:
<-- delay - potentially some pointermove/touchmove/mousemove events -->

I'm not sure if this change in relative mouse/touch event order is
likely to break much code in practice.  Eg. some sites may look for
and ignore mouse events that occur immediately after a touchend as a
heuristic to guess which mouse events are generated from touch (since
there's no API for that today) - they'd miss the mousedown in this
case.  I don't immediately see any good alternatives here - there's a
fundamental conflict between the two approaches to mouse
compatibility, and IMHO the pointer events approach is better (handles
cases like buttons which depress on mousedown).

Received on Thursday, 22 November 2012 17:11:36 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:48:06 UTC