- From: Rick Byers <rbyers@google.com>
- Date: Mon, 14 Apr 2014 19:23:07 -0400
- To: Daniel Freedman <dfreedm@google.com>
- Cc: polymer-dev <polymer-dev@googlegroups.com>, public-pointer-events@w3.org
- Message-ID: <CAFUtAY8ZptjkL1eoUrVvGU=0c3iQyhzUwA+2ggSrNTVPXQg70w@mail.gmail.com>
+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. >
Received on Monday, 14 April 2014 23:23:35 UTC