On Wed, Jul 16, 2014 at 12:19 PM, Zeeshan Qureshi <[email protected]> wrote:
> Folks on input-dev can correct my understanding if its wrong, but >> there's already a first-class notion of a "tap" gesture in Chrome. I don't >> think we expose it, but it's there (eating up resources), so it would be >> really nice to take advantage of it. There's also a gesture recognizer in >> the browser that decides whether you're e.g. scrolling vs tapping. It seems >> a real shame to have this logic running every time the user touches the >> screen, only to have all of that logic re-done (potentially with slight >> differences in behavior) in JS. >> > > I don't think the logic is run twice, Tim can correct me if I'm wrong. If > there is a touch handler, the touch events are dispatched to blink which > can be consumed and prevent defaulted. Only if they are not prevent > defaulted are they fed into the gesture recognizer to generate Gesture* > events and then dispatched to blink. > > Any library that wants to have their own gesture detector would start > consuming them at the touch events level and prevent default them. > It can't quite be that neat, though, because you can still get scrolling with touch event handlers. So a JS gesture library would intercept all touch events and at some point early in a touch stream decide that this wasn't a gesture it was interested in. At that point, the browser would have to look at the touch event stream and decide that this *was *worth scrolling. The conclusions are different, but the logic must be nearly the same... 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/CAK-G-KXTZ7QRs2FaukCL0Pc21pC0yT52BRavSo6MjX8XOdHgMA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
