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

On Fri, Aug 15, 2014 at 3:08 PM, Daniel Freedman <dfreedm@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
<http://extensiblewebmanifesto.org/> 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
<https://developer.apple.com/library/ios/documentation/EventHandling/Conceptual/EventHandlingiPhoneOS/event_delivery_responder_chain/event_delivery_responder_chain.html#//apple_ref/doc/uid/TP40009541-CH4-SW4>,
Android <http://developer.android.com/training/gestures/viewgroup.html>).

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

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.
>
>
> On Thu, Aug 14, 2014 at 2:05 PM, Rick Byers <rbyers@google.com> wrote:
>
>> Hey Daniel,
>> I see you recently marked
>> <https://github.com/Polymer/PointerEvents/commit/b80d4c2f282758e68c0e9805ee3700b0c36256f2>
>> 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
>> <https://code.google.com/p/chromium/issues/detail?id=398920> 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
>>
>>
>>
>> On Tue, Apr 15, 2014 at 9:12 AM, Rick Byers <rbyers@google.com> 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 <dfreedm@google.com>
>>> wrote:
>>>
>>>> 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.
>>>>>
>>>>
>>>
>>
>