PSA: PointerEvents and PointerGestures are being replaced by polymer-gestures, breaking changes for pointer* events

[Daniel Freedman]

Hi Polymer users,

We recently had a big perf investigation of mobile use cases and found that our gesture layer was not performant enough to get 60 FPS[1].

For this reason, I have created the polymer-gestures library which gesture events in a mobile-performant way.

In the next release, polymer-gestures will replace (the now deprecated) PointerGestures, and PointerEvents will be removed from the default build.

These are the supported events of polymer-gestures:

• down
• up
• Same target as down, provides the element under the pointer with the relatedTarget property
• trackstart
• track
• Same target as down
• trackend
• Same target as down, provides the element under the pointer with the relatedTarget property
• tap
• Targets the nearest common ancestor of down and up.relatedTarget
• Can be prevented by calling any gesture event's preventTap function
• flick *
• hold *
• holdpulse *
• release *
• pinchstart *
• pinch *
• pinchend *

* = "Not yet implemented"

If you listen for pointerdown, pointermove, pointerup, pointerover, pointerout, pointerenter or pointerleave, you will need to change your code.

If you require an event for every movement of the pointer, you can use the "track" event.

This change was not made lightly, but only after careful consideration of device constraints and lack of cross-browser PointerEvent implementations.

The Polymer team still believes that PointerEvents are the best technical solution for handling user input, but mobile use cases are too important to be gated on native implementations.

I apologize for the churn.

[1]: The big culprit was the gymnastics the PointerEvents polyfill had to make to be spec compliant and target the correct elements with ShadowDOM.

In particular, the encapsulation mechanics of ShadowDOM made target finding for pointermove very expensive, requiring recursive elementFromPoint calls.

Another large chunk of time was wasted on having gesture recognizers listen for dispatched, normalized pointerevents.

Polymer-gestures will use the lower-level events directly without spinning up the DOM event system N times each pointer movement.

[Rick Byers]

+public-pointer-events

What does this mean for other consumers of the PointerEvents polyfill?  Will it be effectively orphaned?

Follow Polymer on Google+: plus.google.com/107187849809354688692
---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/CAAUAVAgorf1-V2iiB%3Dub02QiJtMd%2BE4cXPzGXK3LrQDCxFXNQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Daniel Freedman]

It is my hope that when PointerEvents has a few more native implementations, then polymer-gestures can transition to being a consumer of PointerEvents only, and we can reinstate the polyfill for other browers.

To that end, I plan to maintain the PointerEvents polyfill to follow the spec as it evolves (thankfully there have been few breaking changes since the WG started).

Unfortunately, the polyfill's performance penalty on mobile is an information problem, and not one I see workarounds for in the near to medium term.

Target finding seems to be expensive no matter which way I try to slice it, and mobile already operates at a tremendous speed disadvantage.

I do not intend this change to be negative signal on the part of PointerEvents, but an (unfortunate) acceptance of the practical realities of mobile devices and polyfill performance.

[Jacob Rossi]

Will the polyfill continue to live here: https://github.com/polymer/PointerEvents?

[Daniel Freedman]

Yes, there are no plans to move it anywhere else.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/a2f5ee249e5d4028862d8dd5998cac6a%40BY2PR03MB457.namprd03.prod.outlook.com.

[Rick Byers]

Thanks Daniel.  I know this was a tough decision for the Polymer team.  I'm glad we can continue to collaborate on Pointer Events and the polyfill!

Rick

[Daniel Freedman]

No, there is no concept of an "over" event, because it requires hit-testing per movement, which is very expensive.

On Fri, Apr 25, 2014 at 11:42 AM, Aleksandar Rodic <aleksa...@google.com> wrote:

Thanks for the update!

Is there a PointerGesture equivalent to 'pointerover' event? Seems like 'track' event only fires when mouse button is pressed.

[Martin Kleinschrodt]

Which release are the implementations for hold, release etc. planned for?

[Daniel Steigerwald]

As I understand the perfomance issue if related to shadow DOM only which I don't use. Also, I never used gestures layer so I can still use Polymer PointerEvents without performance degrade impact?

[Rick Byers]

Hey Daniel,

I see you recently marked the PointerEvents repo as "deprecated".  Does this reflect a change to your position earlier in this thread ("plan to maintain"...)?  Any advice for people in the PointerEvents community looking to use the polyfill in their own projects?

By the way, I'm working on a hit-test cache feature in blink that I hope will (among other benefits) address the shadow DOM hit-test perf problem you hit (without requiring any new shadow-piercing API - yay!).

Thanks,

  Rick

[Daniel Freedman]

Given Blink's decision to not implement PointerEvents natively (http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html), I can't justify keeping the torch lit for the Polymer polyfill to myself anymore.

If there are others who have the time and energy to keep the dream alive, I think the best course of action would be to fork https://github.com/Polymer/PointerEvents, as I and Polymer, and Google won't be the active maintainers.

I will happily answer code questions and be available to review changes if asked.

I do have a few bits of feedback for the pointerevents folks that you might find useful.

As Polymer has progressed as a project, we've found that good UX requires a system that can handle "sloppy" user input, where a mouse or finger could move outside the node with the event handlers.

This case happens quite frequently with dragging interactions, especially on mobile. It doesn't just come up because of poor hand-eye coordination, but because the user can frequently move faster than the event/layout/paint system can handle.

In order to counteract this degenerative case, a developer either has to use pointer capturing for every instance of draggable UI, or add another set of listeners higher up the DOM tree and do some event delegation. This proves to be too great of a burden to development, and necessitated the creation of Polymer's gesture library, which has a TouchEvent-like event targeting system. For all the horrible API of TouchEvents, the event targeting model is almost ideal for user interaction.

Another great observation: no one remembers touch-action. Ever. Everyone gets confused about when they need to use it, and the mirrored directions of the pan-* values. I had to go as far as making "trackx" and "tracky" gestures that just set intended touch-action for dragging interactions.

In addition, no one ever seemed to use over/out/enter/leave. As long as :hover works for touch and mouse, all is well.

In closing, I think this whole exercise just proves how *hard* it is to make an event system. I greatly appreciate everyone's effort, from spec to implementation, and the users. The web ecosystem can only benefit from the experiments and hard work of everyone involved.

[Rick Byers]

On Fri, Aug 15, 2014 at 3:08 PM, Daniel Freedman <dfr...@google.com> wrote:

Given Blink's decision to not implement PointerEvents natively (http://lists.w3.org/Archives/Public/public-pointer-events/2014JulSep/0051.html), I can't justify keeping the torch lit for the Polymer polyfill to myself anymore.

If there are others who have the time and energy to keep the dream alive, I think the best course of action would be to fork https://github.com/Polymer/PointerEvents, as I and Polymer, and Google won't be the active maintainers.

I will happily answer code questions and be available to review changes if asked.

Thanks Daniel.  That's unfortunate but it makes sense.  Thanks for offering to provide guidance to anyone that wants to maintain it.

I also want to emphasize that we care deeply on the blink team about making such libraries possible, high-quality, and easy to write.  We want the web platform to be made out of powerful primitives that allow rapid innovation and experimentation in the libraries/frameworks (where standards bodies that require consensus to succeed are often the worst place to have such debates).  It really shouldn't be a big deal that people can't agree on things like what event names get used in different scenarios (eg. same or different for touch and mouse) and what the structure of the event objects look like (eg. one point per event, or sets of points) - that should just be sugar that's easy to change in a library.  Note that even something as fundamental as the capturing model is easily customizable in other successful platforms (eg. iOS, Android).

So I'm happy to work with anyone that wants to maintain the pointer events polyfill to drive improvements/fixes to blink that help it, and explore advancing new standard primitive APIs that make such things easier to build with high quality.

Rick

[Rich]

There is no reference to touchstart. What is the Polymer equivalent to touchstart?

[Rob Dodson]

I'm guessing it's `down` but +dfreedman can confirm

On Sun, Feb 15, 2015 at 5:11 AM, Rich <learn.mode...@gmail.com> wrote:

There is no reference to touchstart. What is the Polymer equivalent to touchstart?

Follow Polymer on Google+: plus.google.com/107187849809354688692

---
You received this message because you are subscribed to the Google Groups "Polymer" group.
To unsubscribe from this group and stop receiving emails from it, send an email to polymer-dev...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/e8a19612-d744-40ef-9038-e0fe6d451fca%40googlegroups.com.

[Daniel Freedman]

The polymer-gestures equivalent to "touchstart" is the "down" event.

[aazah...@gmail.com]

Hi people, maybe its slightly outdated question about track* events, but 

how I can get shift key status in it?

Thanks.

вторник, 17 февраля 2015 г., 21:43:55 UTC+3 пользователь Daniel Freedman написал:

[Arthur Evans]

I believe that would be event.detail.sourceEvent.shiftKey.

OK
-Arthur

To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/b7cef1cb-2d00-493d-b052-7b3f55c5013c%40googlegroups.com.

[Андрей Захаров]

Hi, thanks for answer. There is no such field "shiftKey" in trackstart event, and I cannot get sourceEvent of it.

That's why I'm asking

Event drag-start has details: {

  event: "trackstart" event

  avatar: "HtmlElement"

}

Event "trackstart" has fields on screenshot. 

Cannot see the way, maybe just tracking in mousemove can helps me... a bit tricky way with side flag.

--

---

Respectfully, Andrey Zakharov

 R277869166454

 Z191476865000

 41001122409780