- From: Rick Byers via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Nov 2016 19:30:59 +0000
- To: public-touchevents@w3.org
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. -- GitHub Notification of comment by RByers Please view or discuss this issue at https://github.com/w3c/touch-events/issues/76#issuecomment-263970690 using your GitHub account
Received on Wednesday, 30 November 2016 19:31:07 UTC