Re: Adding currentTarget to Touch objects

On Sun, May 29, 2016 at 5:35 PM, Olli Pettay <> wrote:

> On 05/29/2016 08:36 AM, Kevin Barabash wrote:
>> I've been working on implementing an onscreen custom keypad.  If the user
>> presses a key, I want them to be able to move to another key in case they
>> made a mistake.  I found it really hard to implement this using Touch
>> Events because a touches are bound to the element that they started on.
>> I'm using React and was able to patch it to add a 'currentTarget'
>> property to changedTouches, touches, and targetTouches.  The implementation
>> uses
>> elementFromPoint.  See for
>> details.
>> So you add currentTarget property to Touch objects, not to the *Touches
> lists, right?
> Anyhow, wouldn't currentTarget be rather hit-testing heavy, so possibly
> affecting significantly to the responsiveness of the web page
> (at least in cases when currentTarget isn't actually needed)?
> Given that it is rather easy to use elementFromPoint when needed, I don't
> see strong reason to add currentTarget.

I agree.  Hit-testing (finding the node at a position) is a non-trivial
operation, and for touch UIs it's often not necessary (or even desirable)
to do this on every movement.  So we wouldn't want to add this to every
TouchEvent by default.  We could have a method like
"Touch.getNodeUnderTouch()" to let developers opt into it when they
actually need it, but this would just be implemented with elementFromPoint
so adding it to the Touch API probably doesn't buy you anything.

Have you investigated if pointer events would fit better in your use case?

Note that we (Chrome team) want pointer events to also have this property
<>, but you could opt-out by
calling "releasePointerCapture".  Then each pointermove would be delivered
to whatever node is under the finger.

> I'm curious what other people think about adding a currentTarget property.
>> Kevin Barabash
>> Khan Academy

Received on Monday, 30 May 2016 15:43:43 UTC