- From: Rick Byers <rbyers@chromium.org>
- Date: Tue, 27 Jan 2015 10:20:58 -0500
- To: Olli Pettay <olli@pettay.fi>
- Cc: Jacob Rossi <Jacob.Rossi@microsoft.com>, "public-touchevents@w3.org" <public-touchevents@w3.org>, Mustaq Ahmed <mustaq@chromium.org>, Matt Gaunt <mattgaunt@chromium.org>, Jake Archibald <jakearchibald@chromium.org>, Daniel Freedman <dfreedm@chromium.org>
- Message-ID: <CAFUtAY_SEKDM4YO3eMZ++jKzXZ2SCzb6k=3Jvddt4Y0b4_FsHA@mail.gmail.com>
On Thu, Jan 22, 2015 at 11:23 AM, Olli Pettay <olli@pettay.fi> wrote:
> 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 think it's possible to do something along these lines, it'll just be
tricky to get right (from both a technical and legal perspective). Eg. in
chromium, putting two fingers down and moving just enough will send a
touchmove which, if unconsumed, will start both a scroll and a pinch-zoom
action. How would that be represented in such an API? What if we can't
use a term like "pinch-zoom"? I do kind of like that "manipulation"
encompasses all of this subtlety.
What additional scenarios are you thinking this richer API would permit?
The main scenarios I'm thinking about would all be addressable with a
combination of the 'startsManipulation' boolean and touches.length (a page
may want to handle one finger but not two finger gestures or vice versa -
but this is more about the gesture than the action the browser will trigger
from it).
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 Tuesday, 27 January 2015 15:21:48 UTC