W3C home > Mailing lists > Public > public-touchevents@w3.org > January 2015

Identifying touch events that will trigger a tap / click

From: Rick Byers <rbyers@chromium.org>
Date: Mon, 5 Jan 2015 12:48:20 -0500
Message-ID: <CAFUtAY9mi9HLq5iMoA9q1jqWOmCwjreafj7iRoy_L819LC1yww@mail.gmail.com>
To: "public-touchevents@w3.org" <public-touchevents@w3.org>
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
Received on Monday, 5 January 2015 17:49:08 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:35:14 UTC