[css-scroll-snap-1] Avoid page scrolling skipping past snappable items

[flackr]

This originally came up from @johannesodland as a potential issue with scroll-buttons in #10722 (comment) however it's a pre-existing generic issue with scroll-snap, so filing it separately.

When a user pages down, usually by pressing the page-down key, they expect to scroll no further than one page if that is a valid scroll location. However, some browsers can select the next snap point as the target resulting in a scroll of more than a scrollport in length.

E.g. if you have a scrollport height of 1000px, most browsers will try to scroll by 850px. If however the nearest snappable element has a snap alignment that is further, then it can be selected, resulting in scrolls even greater than 1000px and an experience where content has been skipped over - even when that content itself defined a valid snap area. We should fix this so that it's easy to make an experience where

Codepen demo using page-down key: https://codepen.io/flackr/pen/abgeOKY
Original demo from @johannesodland using scrollTo api: https://codepen.io/johannesodland/pen/WNqmoYy

[flackr]

Naively for built-in interactions, the UA could do something like select a snap area which scrolls no further than 100% of the scrollport if possible, though I wonder if there's some way we could make this work for programmatic scrolls as well as in the scrollTo example?

E.g. we could say that for any scrolls less than or equal to 1 scrollport, we try to select a snap area which keeps the scroll less than that distance. I say "try" because developers can position snap areas arbitrarily far apart and we should make some progress in the requested scrolling direction.

[flackr]

Alternately a more generic option could be to snap in a way that scrolls no more than the requested distance if possible. This would ensure that page-down never scrolls more than 85% unless that is necessary to go to the next snap area.

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap-1] Avoid page scrolling skipping past snappable items, and agreed to the following:

• RESOLVED: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
• ACTION: flackr to sketch out a scroll-by-page API

The full IRC log of that discussion

flackr: context of scroll buttons , but pre-existing issue with snapping
flackr: currently if you pgae down, the browser can select a snap area that is more than one page away
flackr: even though there's a possible snap area that's not that far away
flackr: I propose putting wording in the spec that, at least for explicit actions like page down, find a snap area that is less than one page away
flackr: so that you don't skip over content
flackr: then I had a further open question of whether we need to solve this for scrolling APIs
flackr: original issue was calling .scrollTo
flackr: to mimic same behavior
fantasai: I think yes, page-up page-down should scroll <= viewport
fantasai: might be exactly equal, but could be <=
fantasai: for programmatic API, those are supposed to [...]
ack fantasai
fantasai: ...have the same behavior as a person scrolling
fantasai: if scroll-snap is going to interfere with a person scrolling, then programmatic aPI should get that same interference
flackr: if I make a page-down button, as a web developer, and add an event listener that calls scrollTo(currentPos + 85% of scrollport)
flackr: the same problem as pressing pagedown on keyboard exists, that browser could select something further away
flackr: should we try to scroll less?
fantasai: round-down version?
flackr: most expressive version is to say "don't want to scroll more than 1 page"
fantasai: ...
flackr: that's scrollIntoView
flackr: this is for APIs where you specify how far you want to scroll, or a position
fantasai: do we want to add a scrollByPages API?
flackr: that would be reasonable
fantasai: or do we give a "bias-towards" parameter?
fantasai: which of those would make more sense
flackr: I feel like we'd be more likely to do what the dev expects, if the API was specifically "scroll by a page"
fantasai: I guess then we have 2 resolutions?
fantasai: (1) pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
PROPOSED RESOLUTION: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
RESOLVED: pageUp/pageDown type operations should never scroll by more than a page, unless that's the only valid snap area
fantasai: (2) we want to add some kind of scroll-by-page type API, to be sketched out by flackr
flackr: I can sketch that out
Rossen6: no need to resolve on that now
ACTION: flackr to sketch out a scroll-by-page API
FWIW there is a scrollByPages API in Firefox, non-standard: https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollByPages

[flackr]

From @dholbert:

FWIW there is a scrollByPages API in Firefox, non-standard: https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollByPages

[dholbert]

From @dholbert:

FWIW there is a scrollByPages API in Firefox, non-standard: https://developer.mozilla.org/en-US/docs/Web/API/Window/scrollByPages

Indeed; I'm pretty sure this is how we implement the Space/PageDown and PageUp scrolling actions under-the-hood (as calls to scrollByPages(1) and scrollByPages(-1), from Firefox's frontend JS). But the JS API is also exposed to the web, too, for historical reasons I guess.

The scrollByPages() implementation is here if anyone's curious to see it. That function calls a generic C++ ScrollBy() function that's shared by a bunch of programmatic scrolling APIs, and the most relevant piece there for scrollByPages is the GetPageScrollAmount() function, which defines what it means to scroll by a page.

[argyleink]

could we make snapping more conservative and choose the nearer of the points instead of the further?