Re: Identifying touch events that can trigger scrolling

On 01/22/2015 05:34 AM, Rick Byers wrote:
> 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
is it 'can' or 'may'.

Perhaps we don't want a boolean attribute but enum attribute to indicate which action the UA
tries to do.

enum {
   "",
   "horizontal-scroll",
   "vertical-scroll",
   "scroll"
};

[NoInterfaceObject] interface EventManipulation {
   readonly attribute ManipulationType defaultManipulation;
};

TouchEvent implements EventManipulation;
PointerEvent implements EventManipulation; // if we want something like this too.



(Though, I don't like the word 'manipulation'. 'action' might be better)


-Olli

> - lastCancelableEvent
This makes really no sense ;)

>
> Rick
>
> On Tue, Jan 20, 2015 at 1:41 AM, Jacob Rossi <Jacob.Rossi@microsoft.com <mailto:Jacob.Rossi@microsoft.com>> wrote:
>
>     At first glance defaultStartsManipulationseems 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> [mailto: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 <mailto: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 <mailto: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____
>
>         __ __
>
>     __ __
>
>

Received on Thursday, 22 January 2015 12:24:55 UTC