Re: What happens to touchend/touchcancel when touchstart target no longer present?

Hi Nathan,

On Sat, Nov 3, 2012 at 6:39 PM, Nathan Vander Wilt <nate-lists@calftrail.com
> wrote:

> I'm worried about the implications of the touchend/touchcancel event
> definitions in a situation where touch events drive DOM modifications.
> Mouse up events are fired at the element the mouse is *currently over*,
> while the Touch Events specification(s) say the following:
>
> "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 thetouch
> point has since moved outside the interactive area of the target element."
> http://www.w3.org/TR/touch-events/#the-touchend-event /
> https://dvcs.w3.org/hg/webevents/raw-file/tip/touchevents.html#the-touchend-event
>
> What is to happen if the element on which the touchstart event was
> originally fired is no longer in the DOM? This case is actually quite
> common in web map applications, where the finger typically starts on the
> DOM element of a map tile or marker that which very well get removed
> throughout a continuous gesture.
>

The events continue to fire at the element (and bubble according to current
parent chain, i.e. go nowhere else for a detached node).

I would have expected that (as with mouse events) simply registering
> touchmove/touchend/touchcancel events on the window would be sufficient,
> but unless there is some underlying specification that would have the touch
> events re-targetted when necessary this seems like a serious issue in the
> specification.
>

I agree that would be desirable, and it's surprising that you can't just
listen for all events on the document and get a consistent start/end/cancel
sequence of events.  I agree this could be a common scenario (eg. I'm sure
we must have hit this in mobile gmail where we control scrolling of the
list of messages via touch events, while also adding new messages to that
list).  Note that this is also a problem when moving nodes around (not just
when removing them).

Losing events for a finger at the window level just because its touch was
> unlucky enough to land on a replaced child element is a big problem. Could
> the specification be changed to clarify that this is not the intention?
>

The specification was written after several important implementations and
so is designed mostly to reflect the behavior there.  Since the problem is
with the existing implementations, I don't think there is a spec issue here
(although we could certainly make the spec call this implication out more
clearly).  I think applications just need to be aware of this behavior, and
compensate if desired eg. by adding touch event handlers to nodes being
removed while there is an active touch on that node (or perhaps by
re-inserting the element into the dom elsewhere where it's not visible but
will still bubble events up to the handler).

I agree this seems like a flaw in the model.  Pointer events, thankfully,
don't have this problem: http://www.w3.org/Submission/pointer-events/.
 Personally I believe moving to pointer events is probably the right
long-term solution.

regards,
> -natevw
>
>