Which release are the implementations for *hold*, *release* etc. planned for?
On Friday, April 25, 2014 9:34:20 PM UTC+2, Daniel Freedman wrote: > > 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 > <[email protected]<javascript:> > > wrote: > >> Thanks for the update! >> >> Is there a PointerGesture equivalent to 'pointerover' event? Seems like >> 'track' event only fires when mouse button is pressed. >> >> >> On Tuesday, April 15, 2014 6:12:51 AM UTC-7, Rick Byers wrote: >> >>> 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 >>> >>> >>> On Mon, Apr 14, 2014 at 11:58 PM, Daniel Freedman <[email protected]>wrote: >>> >>>> Yes, there are no plans to move it anywhere else. >>>> On Apr 14, 2014 8:18 PM, "Jacob Rossi" <[email protected]> wrote: >>>> >>>>> Will the polyfill continue to live here: https://github.com/polymer/ >>>>> PointerEvents? >>>>> >>>>> >>>>> >>>>> *From:* Daniel Freedman [mailto:[email protected]] >>>>> *Sent:* Monday, April 14, 2014 4:42 PM >>>>> *To:* Rick Byers >>>>> *Cc:* polymer-dev; [email protected] >>>>> >>>>> *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 <[email protected]> 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" <[email protected]> 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 [email protected]. >>>>> >>>>> 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 [email protected]. >>>>> >>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/polymer-dev/a2f5ee249e5d4028862d8dd5998cac >>>>> 6a%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. >>>>> >>>> >>> > 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/polymer-dev/dd17c7e1-39f1-486e-8368-ff3beb883171%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
