Re: Identifying touch events that can trigger scrolling

On 01/22/2015 06:05 PM, Rick Byers wrote:
> On Thu, Jan 22, 2015 at 7:24 AM, Olli Pettay <olli@pettay.fi <mailto:olli@pettay.fi>> wrote:
>
>     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'.
>
>
> I'm not sure which is more correct.  It's "will attempt to scroll/zoom if uncancelled".  Hence Ben's "defaultStarts..' suggestion.
>
>     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"
>     };
>
>
> This is basically the same idea Ben proposed here <https://bugs.webkit.org/show_bug.cgi?id=138151> and we discussed on the call.  Jacob expressed
> concern with trying to be general like this because we'd have to also include actions like "zoom" and we may quickly run up against UA-specific
> behavior (eg. how gestures map to actions) that we don't want to try to force UAs to agree on (and would be unable to standardize in W3C given the
> current IP climate anyway).

Well, we'd standardize the parts we can, and have "ua-specific" for the other cases?


>
> I'm also not sure that's that much additional value to reporting the different actions explicitly.  When used with touch-action you can suppress the
> actions you want to implement yourself in JS and then you know that any other "mayStartManipulation" event is for one of the remaining action types.
>
> But I'd personally be happy to go down this route if we had a concrete example where it is better for developers than the simpler bool option.
>
>     [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> <mailto: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>> [mailto: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> <mailto: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
>         <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 <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-__WafO91JehdjNVGRAkOQHCSYbFju8M9__0A4Xt1s-A8/edit#heading=h.__ay2pmk927mpu
>         <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
>         <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> <mailto: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 <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()
>         <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
>         <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 16:23:36 UTC