Re: Identifying touch events that can trigger scrolling

Thanks Jacob!

Other potential name ideas (I'm not interested in bike-shedding over it
either - any of these would be fine with me):
- triggersManipulation
- canStartScroll
- lastCancelableEvent

Rick

On Tue, Jan 20, 2015 at 1:41 AM, Jacob Rossi <Jacob.Rossi@microsoft.com>
wrote:

>  At first glance defaultStartsManipulation seems reasonable (not crazy
> about the name, but even less crazy about bikeshedding over it). I want to
> take a look at some of the pages we’ve seen using crude JS gesture
> recognizers & magic numbers to determine if a manipulation is going to
> occur and see how easy something like this is to swap in.
>
>
>
> -Jacob
>
>
>
> *From:* rbyers@google.com [mailto:rbyers@google.com] *On Behalf Of *Rick
> Byers
> *Sent:* Monday, January 19, 2015 8:32 AM
> *To:* public-touchevents@w3.org
> *Cc:* Mustaq Ahmed; Matt Gaunt; Jake Archibald; Daniel Freedman
> *Subject:* Identifying touch events that can trigger scrolling
>
>
>
> In last week's TECG call
> <http://www.w3.org/2015/01/13-touchevents-minutes.html>, we agreed that
> the below problem of identifying touch events that can trigger a click is
> interesting mostly for browsers that don't have an API for disabling the
> click delay and that adding such an API is probably a superior solution for
> those scenarios.
>
>
>
> However, the very related (often inverse) problem of identifying touch
> events which can cause a scroll to start is still very interesting for all
> browsers.  We liked Ben's proposal
> <https://bugs.webkit.org/show_bug.cgi?id=138151> of adding an API to
> touch events for indicating what actions they can trigger, but prefer to
> start small focused on concrete actions they can trigger.  In particular,
> an API defined in terms of touch gestures (like "pinch" and "double tap")
> is unlikely to be standardizable in the current IP climate.
>
>
>
> Based on this discussion, I've written up a concrete proposal
> <https://docs.google.com/a/chromium.org/document/d/1Rf-WafO91JehdjNVGRAkOQHCSYbFju8M90A4Xt1s-A8/edit#heading=h.ay2pmk927mpu>
> for addressing the "when will scrolling start" problem.  Essentially this
> adds a boolean to touchmove events called "defaultStartsManipulation" (with
> some connection to the touch-action specification).
>
>
>
> Jake/Matt: in particular I expect this to address the concern
> <https://groups.google.com/a/chromium.org/forum/#!searchin/input-dev/mattgaunt/input-dev/Bo5FyTLljwY/aZVWhHV04AwJ>
> you raised awhile back about custom side-swipe and the lack of touchcancel
> events - especially if we can get a common API supported in all major
> browsers.
>
>
>
> Feedback (here or as comments in the doc)?
>
>    Rick
>
>
>
> On Mon, Jan 5, 2015 at 12:48 PM, Rick Byers <rbyers@chromium.org> wrote:
>
>  Sometimes it's useful to detect a 'tap' gesture from JavaScript from the
> touch events, before the mouse events (click, etc.) are fired.  For
> example, popular libraries like FastClick
> <https://github.com/ftlabs/fastclick> need to do this for browsers that
> don't have a better way to disable the 300ms click delay (but there are
> other scenarios as well).
>
>
>
> Many apps / libraries implement a simple heuristic for this like "look for
> a first-finger touchstart, followed by 0 or more touchmoves which are less
> than N pixels from the start, then a touchend" This is relatively simple
> and works alright in practice most of the time.  But the developer's
> intention is that it should match the browser's tap detection logic
> EXACTLY.  If the logic mis-identifies a tap, then you could get double
> handling (JS behaving as a tap but the browser triggering a scroll).  If,
> on the other hand, the logic fails to identify a tap it may feel harder to
> activate a control, or activation behavior may be inconsistent.
>
>
>
> There are a number of reasons why such application logic can never be
> perfect:
>
>    1. The value of N can vary.  Eg. on Android, device OEMs can control
>    the ViewConfiguration::getScaledTouchSlop
>    <http://developer.android.com/reference/android/view/ViewConfiguration.html#getScaledTouchSlop()>
>    value used by browsers to implement tap detection.
>    2. The browser may use an algorithm more complex than a simple
>    bounding box.  Extreme example: in iOS UIWebView (and WKWebView) the native
>    application has control over the gesture recognizer graph and can
>    arbitrarily influence detection logic.
>
>  All in all, it seems web developers should really have a way of asking
> "will this touchend cause a click event to be generated if it's not
> canceled?".
>
>
>
> I discussed this problem a bit with Benjamin Poulin on the Safari team
> here: https://bugs.webkit.org/show_bug.cgi?id=138151.  He proposes a
> property on TouchEvent ("eventCanStartDefault") which somehow indicates
> which gestures would be started by the default action of the event ("Tap",
> "Pan", "Pinch", etc.).  I'd be happy to add something like this to chromium
> as well (due to a recent re-architecture it's actually quite easy for us to
> implement).
>
>
>
> Thoughts?
>
>    Rick
>
>
>
>
>