w3c / touch-events

https://w3c.github.io/touch-events/
26 stars 24 forks source link

Adding the fling intervention behavior to TouchEvent's spec #76

Closed LanWei22 closed 2 years ago

LanWei22 commented 7 years ago

Under '5.4 Cancelability of touch events', I want to add a new paragraph.

'While there is an active fling animation, all the touch events generated from a user agent on the active flinging layer may be uncancelable.'

Please free feel to comment on this.

Below is the link to the intent-to-ship draft, https://docs.google.com/document/d/16D5Hle3-zG_kXjXJbQALD2OWOLmsMkGz1r1BthE2V7Q/edit

Thank you!

LanWei22 commented 7 years ago

@RByers, @dtapuska,

RByers commented 7 years ago

I think the spirit of that change is reasonable. Basically if you touch on something that's currently scrolling due to momentum from a previous touch, you shouldn't have any more expectation that you can interrupt the scrolling than for the case of during a scroll. The spec already allows this but doesn't describe the specific cases in detail. Edge has this property already and I believe @staktrace said Gecko did (or would) as well.

But I think we need to bikeshed the wording a bit. Today we have:

For maximum scroll performance, a user agent may not wait for each touch event associated with the scroll to be processed to see if it will be canceled. In such cases...

I think you're just describing a specific instance of this. Perhaps we can make it a bit more precise with language like this:

For maximum scroll performance, a user agent may not wait for each touch event associated with the scroll to be processed to see if it will be canceled. In particular, User Agents may not suspend the motion of an element which is currently moving due to a touch scroll, either as a result of an earlier event in the touch sequence, or due to momentum left over from a previous touch sequence. In such cases...

This is all somewhat hand-wavy, but I think something like this gets across the key principle that matters most, i.e. "objects in motion tend to stay in motion" ;-). Filed #77 to separately explore testing to help compensate for the interop risk here.