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

> Does Chrome apply a directional lock of sorts for scrolling such that starting panning in a predominantly horizontal direction prevents any scrolling in the vertical direction?

Yes. Chrome does do the direction locking for touch scrolling. It is called railing. However, it only holds it if the user doesn't move a substantial amount in other directions. If they do then railing breaks. Here is an [example](https://output.jsbin.com/cigobit). If you start scrolling horizontally if the finger moves slightly vertically we don't do vertical scroll. But if you move the finger enough in the vertical direction then it starts scrolling in that direction as well. The railing logic has nothing to do with touch-action values though.

> If there is such a directional lock, is there a specification that defines this behavior? Under what conditions does that happen? From anecdotal testing, it would appear that, in Chrome, this is tied to the presence of a unidirectional panning restriction using the touch-action property.

As far as I recall there was no specification around the railing logic that Chrome does. However, it is not quite locking either. It is more of a user experience as users are still allowed to scroll in other directions with just a little more movement in the other directions to start it. It is more of a UA behavior to account for the touch sensitivity of screens. Since it is not exactly locking the scroll do you still think a spec is valuable in this space? Also as I mentioned the railing behavior has nothing to do with touch-action.

Note that there is another concept called scroll latching. Sometimes the vertical scroller is the document scroller for example and horizontal scroller is some inner scroller. In that case when we latch to a scroller for the rest of the duration of the scroll only that scroller will scroll regardless of those direction changes (for touch scrolling) and what not. So even if user changes direction if that very scroller that starts the scroll can support scrolling in that new direction (it will break railing) and starts scrolling in that direction. If not just nothing happens. This concept is different from the railing I described earlier. Here is an [example](https://output.jsbin.com/cakaqip) you can try. When playing with this example Chrome does latch to a scroller that the scrolling starts on. But doesn't lock the direction of the scroller. It is just that each of the scrollers (one on the document and one on the div with id="scroller") only supports on direction of scrolling. The scroll chains and latching to a scroller is spec'ed [here](https://drafts.csswg.org/css-overscroll/).

There isn't much of a heuristic around it. It doesn't have much do to with the touch-action either. We have 3 direction locking essentially. If after touch point moves out of the slop region the direction is mostly vertical from that point on we ignore all the horizontal deltas. The same for horizontal scrolling and diagonal

Even if the page is not scrollable and user drags the finger on the page Chrome sends a pointercancel regardless of the scroller (as you can see in [this page](https://output.jsbin.com/tikegig))






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

Received on Friday, 30 August 2019 20:33:12 UTC