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

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.

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.
>>>>
>>>
>>
>