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

Yes, there are no plans to move it anywhere else.
On Apr 14, 2014 8:18 PM, "Jacob Rossi" <Jacob.Rossi@microsoft.com> wrote:

>  Will the polyfill continue to live here:
> https://github.com/polymer/PointerEvents?
>
>
>
> *From:* Daniel Freedman [mailto:dfreedm@google.com]
> *Sent:* Monday, April 14, 2014 4:42 PM
> *To:* Rick Byers
> *Cc:* polymer-dev; public-pointer-events@w3.org
> *Subject:* Re: [polymer-dev] PSA: PointerEvents and PointerGestures are
> being replaced by polymer-gestures, breaking changes for pointer* events
>
>
>
> 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.
>
>
>
> On Mon, Apr 14, 2014 at 4:23 PM, Rick Byers <rbyers@google.com> wrote:
>
> +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.
>
>
>
> 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/a2f5ee249e5d4028862d8dd5998cac6a%40BY2PR03MB457.namprd03.prod.outlook.com<https://groups.google.com/d/msgid/polymer-dev/a2f5ee249e5d4028862d8dd5998cac6a%40BY2PR03MB457.namprd03.prod.outlook.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>