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

+public-pointer-events

What does this mean for other consumers of the PointerEvents polyfill?
Will it be effectively orphaned?
On Apr 14, 2014 7:15 PM, "Daniel Freedman" <dfreedm@google.com> wrote:

> 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.
>
> 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+unsubscribe@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<https://groups.google.com/d/msgid/polymer-dev/CAAUAVAgorf1-V2iiB%3Dub02QiJtMd%2BE4cXPzGXK3LrQDCxFXNQQ%40mail.gmail.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>