New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
majido opened this Issue Jun 22, 2017 · 6 comments

Comments

Projects
None yet
4 participants
@majido

majido commented Jun 22, 2017

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

This comment has been minimized.

Show comment
Hide comment
@majido

majido Jun 22, 2017

@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.

majido commented Jun 22, 2017

@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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jul 14, 2017

Member

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.

Member

tabatkins commented Jul 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@tabatkins

tabatkins Jul 14, 2017

Member

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.

Member

tabatkins commented Jul 14, 2017

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 fantasai closed this in 09eac57 Jul 14, 2017

@fantasai

This comment has been minimized.

Show comment
Hide comment
@fantasai

fantasai Jul 14, 2017

Contributor

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!

Contributor

fantasai commented Jul 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@majido

majido Jul 17, 2017

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

majido commented Jul 17, 2017

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

This comment has been minimized.

Show comment
Hide comment
@css-meeting-bot

css-meeting-bot Jul 19, 2017

Member

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/w3c/csswg-drafts/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
Member

css-meeting-bot commented Jul 19, 2017

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/w3c/csswg-drafts/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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment