[css-scroll-snap-1] Clarify passing by requirement of scroll-snap-stop for different category of scrolling

[majido]

Definition of scroll-snap-stop refers to the concept of passing by a snap position during the execution of a scrolling operation however the specification does not define what exactly considered passing by for different scrolling categories. I suspect, for best UX we may want to have a different definition of passing by for different scroll categories.

For examples for scrolling operations with only intended end position what is considered passed by?

1. Any element in the "corridor" that the snapport defines as it moves through the scrollable overflow region is considered passed by.
2. Only elements in the snapport after scroll position is at the natural end-point.

Definition 1 seems like a reasonable definition but I think we actually want definition 2 for scrolls with only intended end. Not only it matches the definition used for visibility requirement for such scrolls but also it provides a better UX IMHO. For examples consider a page that has a mandatory snap stop in the middle and the user pans all the way to the bottom of the page and releases their finger (or tabs to get to the only focused element at page bottom). First definition forces them to go back to the middle of the page as we cannot pass that snap point which I don't think is the intended/expected behavior.

For scrolls with only intended direction. I think the correct definition is actually the definition 1.

Also according to earlier IRC discussion[1], for scrolls with intended direction and end position we want definition 2. Because an inertial scroll is expected to be able to pass a mandatory stop.

[1]

11:47 AM <fantasai> majidvp: mandatory vs proximity isn't about stopping, it's about whether the scroll position must be at a snap position or not
11:47 AM majidvp: You can scroll past a mandatory stop on inertia. You just can't stop on a position that isn't snapped
11:48 AM majidvp: It's a different concept, whether you pass through the stop on inertia or not vs whether when you "land" you are pushed to the nearest snap position or not

[majido]

@fantasai I am confused by how to interpret the requirement for "scroll-snap-stop" to get the right intended effect. As per your suggestion I filed this issue.

[tabatkins]

The core thing here is that scroll-snap-stop is about draining the momentum out of a fling, so you don't overshoot by accident. If the scroll doesn't have momentum, scroll-snap-stop has nothing to do with it. This can be made clearer, tho.

[tabatkins]

So yeah, end-point-only scrolls are definitely not affected by scroll-snap-stop at all. Direction-only scrolls aren't affected, because they always stop at snap points anyway, I think. (Like, if the next snap point is 10px down, and pressing the Down arrow normally moves you 30px down, you'll still stop at that snap point automatically, I think?)

Only direction+endpoint scrolls (momentum-based flings) actually care about scroll-snap-stop.

[fantasai]

Okay, the definition now reads

When scrolling with an intended direction, the scroll container can “pass over” several possible snap positions (that would be valid to snap to, if the scrolling operation used the same direction but a lesser distance) before reaching the natural endpoint of the scroll operation and selecting its final scroll position. The scroll-snap-stop property allows such a possible snap position to “trap” the scrolling operation, forcing the scroll container to stop before the scrolling operation would naturally end.

Values are defined as follows [...]

This property has no effect on scrolling operations with only an intended end position, as they do not conceptually “pass over” any snap positions.

@majido, let us know if this seems clear enough!

[majido]

After chatting with @syj10 we are happy with the wording. It is now clear that it only affects scrolling with intended directions.

[css-meeting-bot]

The CSS Working Group just discussed Clarify passing by requirement of scroll-snap-stop for different category of scrolling, and agreed to the following resolutions:

• RESOLVED: Accept this edit and close issue 1552 as resolved

The full IRC log of that discussion

<dael> Topic: Clarify passing by requirement of scroll-snap-stop for different category of scrolling
<dael> github: https://github.com//issues/1552
<dael> fantasai: We made some changes to clarify scroll snap stop in respect to different types of scrolling. New definition:
<fantasai> When scrolling with an intended direction, the scroll container can “pass over” several possible snap positions (that would be valid to snap to, if the scrolling operation used the same direction but a lesser distance) before reaching the natural endpoint of the scroll operation and selecting its final scroll position. The scroll-snap-stop property allows such a possible snap position to “trap” the scrolling operation, forcing the scroll containe[CUT]
<fantasai> Values are defined as follows [...]
<fantasai> This property has no effect on scrolling operations with only an intended end position, as they do not conceptually “pass over” any snap positions.
<TabAtkins> Sorry, finally here.
<dael> fantasai: What we decided was it has no effect on a scroll that has an end point but no direction. That includes scrolls where you jump to an element or if you are driving or panning and let go at that point as you're dragging.
<dael> fantasai: Things with a direction like down arrow and page down and momentum scroll are tracked by scroll-snap stop
<dael> astearns: And I see one comment liking to wording.
<dael> fantasai: MaRakow looked it over and sent some comments. We replied. That was offline.
<dael> MaRakow: It seems generally fine. Main thing interesting is the previous lang talked about container, it seemed, though it was in the seciton about elements. I'm generally fine with the defintion unless [missed]
<dael> astearns: Anyone else have an opinion?
<dael> astearns: Objections to closing this issue as resolved?
<dael> RESOLVED: Accept this edit and close issue 1552 as resolved