Capture semantics for a node that moves between documents

Should the spec say something about how capture behaves on a node that
moves between document?

I came across a bug I filed for a real-world issue I saw here with touch
events (details below), and it's not clear to me if pointer events and the
explicit capture API make this any better.

Rick

---------- Forwarded message ----------
From: Rick Byers <rbyers@chromium.org>
Date: Wed, Jul 16, 2014 at 10:55 AM
Subject: Touch semantics when touched node changes documents (eg. polymer
templates)
To: "public-touchevents@w3.org" <public-touchevents@w3.org>
Cc: polymer-dev <polymer-dev@googlegroups.com>, input-dev <
input-dev@chromium.org>


Hi,
We've talked before about some of the implications of the implicit capture
targeting model used by touch events.  Eg. that removing a node while
touching it has surprising (but workable) behavior
<https://plus.sandbox.google.com/+RickByers/posts/GHwpqnAFATf> [1].  And
we've also talked about how multiple active touches in separate documents
<http://www.w3.org/TR/touch-events/#touchevent-implementer-s-note> [2]
should behave.

But I've never heard any discussion about what browsers should do if a node
moves documents while the target of a touch.  Here's a test page
<http://jsbin.com/hupuci/1/edit> [3] that shows Safari and (prior to a
crash I accidentally introduced <http://crbug.com/393822> [4]) Chrome
appears to just stop sending any events in such a situation (not visible to
the target node, original document, or new document).

This seems problematic since the code handling the touch events may be
logically separate (in another component, even owned by a different
organization) than one that may be manipulating the DOM.  For example,
imagine some infinite news feed (facebook etc.) with JavaScript-driven
touch scrolling.  DOM elements may come and go (possibly to/from transient
documents for staging purposes or nested iframes for isolation reasons)
based on network activity disconnected from scrolling.  It shouldn't be
necessary (even if it's desirable for performance reasons) to
co-ordinate/suppress the DOM manipulation code with the touch handling code.

I'm surprised I've never heard anyone complain about this before.
Presumably it's one of those rare "touch doesn't work right but I don't
understand why" cases.  Polymer's implementation of <template> elements
<https://github.com/Polymer/TemplateBinding/blob/3168309eb131921f08e3a74e9d7197c903762bda/src/TemplateBinding.js#L1085>
(the scenario I saw this hit in) could make this more common.  I've filed a
bug <http://crbug.com/394339> to track addressing this in blink somehow.

What do you think.  Do you agree this is something that should be addressed
to improve rationality?  I've got a couple possible ideas, but I'd like to
here from others.

Thanks,
   Rick

[1] https://plus.sandbox.google.com/+RickByers/posts/GHwpqnAFATf
[2] http://www.w3.org/TR/touch-events/#touchevent-implementer-s-note
[3] http://jsbin.com/hupuci/1/edit
[4] http://crbug.com/393822
[5]
https://github.com/Polymer/TemplateBinding/blob/3168309eb131921f08e3a74e9d7197c903762bda/src/TemplateBinding.js#L1085
[6] http://crbug.com/394339