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