Re: [pointerevents] touch-action and scrolling directional lock (#303)

My bad. I actually did build all those examples of mine based on your example but when replying to your last comment I just tried it on the phone and forgot what the code was doing. You are right that there is indeed no second scroller. Only the main document vertical scroller.

So Chrome in general decides to think about scrolling when touch point moves beyond slop region. At that point Chrome knows the (at least initial) direction of scrolling. Based on that it first looks at the touch-action. If it is allowed then it sends a pointercancel and start looking into scroll chain and finding the latched scroller for that direction and scrolling. If it is not allowed it gives up the scrolling altogether for the rest of the time it is on the screen regardless of which direction it moves. I believe we followed this text from the spec although it doesn't call this touch direction changes explicitly:

"Once a touch action has been started, and the user agent has already determined whether or not the action should be handled as a user agent touch behavior, any changes to the relevant touch-action value will be ignored for the duration of the touch action"

However, I cannot think of a scenario now that why we cannot start scrolling if the direction really changes and goes in a direction that touch-action allows. Then I assume we would need to send a pointercancel. Although I need to think about this a little more to make sure whether there is anything going wrong as a result of that.

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

Received on Wednesday, 11 September 2019 02:25:54 UTC