Re: [pointerevents] Imperative API to request suppression of panning and zooming

> If we go for a Promise-based approach, the involved delay should be obvious in the API IMO. In particular, tryDisableTouchActions could be misleading because the name seems to suggest "disable now if possible" (as if the Promise would complete immediately---rejected if panning/zooming has started already, resolved otherwise). Does disableTouchActionOnLongPress sound better?

I'm actually proposing it DOES disable immediately if possible.  In practice it should resolve very quickly (in chromium it's just an async mojo call to the browser process, so latency really depends only on the availability of the main thread when the call completes).

That's what makes this approach more flexible - the app can decide itself when and under what conditions it wants to try to suppress scrolling (eg. maybe it's when three fingers go down, or some other atypical gesture).

> Isn't the Promise really just a proxy for allowing a delayed touch-action to be set? I still don't like the unpredictability of these approaches. I'd prefer a css driven approach where we indicated that say a touch-action: none is applied after x milliseconds if the gesture hasn't started. That is an exact definition of the problem we are trying to solve.

It's indeed more predictable to do it entirely declaratively.  Eg. if the main thread has 200ms of jank, then what's supposed to be a 1s timeout could actually behave like a 1.2s timeout.  If we can agree on a single model (exact timeout value, etc.) and can't come up with any other realistic use case, then I agree that #178 is probably the better solution.  But I'm worried there's maybe a long-tail of problems here.  Maybe we'd say the right completely general answer there is explaining `touch-action` in terms of an [AnimationWorklet](https://wicg.github.io/animation-worklet/)?  

> Is there any chance we may also want to allow setting another touch-action rather than just consuming the active event stream?

Yeah I thought about that to - maybe even a 'requestUpdateTouchAction()' API that just asks that the CSS style be re-evaluated for the in-progress gesture.  I couldn't come up with any realistic reason that additional flexibility was likely to be valuable, and it seemed more complicated to me (a complex JS/CSS interaction, instead of what is conceptually a JS API that's exposes a piece of the primitives underlying the higher-level CSS concepts).  Dunno though.

-- 
GitHub Notification of comment by RByers
Please view or discuss this issue at https://github.com/w3c/pointerevents/issues/216#issuecomment-328201964 using your GitHub account

Received on Friday, 8 September 2017 20:09:45 UTC