[cssom-view] extend scrollIntoViewOptions' *ScrollLogicalPosition* with `"farthest"` and `"none"`

[Schepp]

Relevant spec: https://w3c.github.io/csswg-drafts/cssom-view/#enumdef-scrolllogicalposition

While Element.scrollIntoView() got a lot more practical with the current ScrollLogicalPosition block and inline values, there is still some scenarios that would benefit from additional options that are "farthest" and "none".

In both cases, the scenario is that we've created a scroll slider whose items are at such a narrow size, that you would see e.g. three of them at once with the fourth being cut off at the border.

The slider has arrow key support as well as programmatic scroll buttons on both sides. We use IntersectionObserver to keep track of the visibility of each item in the slider, so that we can determine which item to scroll into view when the user strikes an arrow key or clicks one of the two directional scroll buttons:

• arrow key / button click towards end: last item from the start with < 1.0 intersection
• arrow key / first item with < 1.0 intersection after a series of items with 1.0 intersection

CodePen example: https://codepen.io/Schepp/pen/KKeyaJx

Now to how "farthest" and "none" ScrollLogicalPosition can help us here:

• "farthest": when a user triggers a scroll further towards one direction, what we want is to grab the first not / not fully visible item in that direction and to scroll it not just slightly into view, but all the way up to the opposite end of the visible area, thereby unveiling a lot more items behind it. The only way to realize this at the moment is to swap between inline: "start" and inline: "end" depending on the direction chosen by the user. While this is not that hard to do, the code could be simplified with an inline: "farthest" - also given that there is the option "nearest".

• "none": depending on the screen size and the scroll position the slider might be cut off somewhere in block direction. Now when a user triggers a programmatic scroll, either by striking an arrow key or clicking a scroll button, what happens is that not only does the inner part of the slider scroll in the inline direction, the whole slider itself will also scroll into view in block direction, if cut off. This is a bit irritating. It gets downward bad UX the moment it is wired to autoforward using that same programmatic code as every time it scrolls, it will pull the viewport to show it again. I currently stop that to happen by observing the slider itself via IntersectionObserver and pausing autoforward once it gets cut off. An ideal solution for this would be to extend ScrollLogicalPosition with a "none" option, so that we can set block: "none" and be good.

[argyleink]

farthest is a great term for what i consider "paging" through the items: snap to the next not-in view item which reveals a new page/set of items 👍🏻

not only does the inner part of the slider scroll in the inline direction, the whole slider itself will also scroll into view in block direction, if cut off. This is a bit irritating.

totally agree and I've brought it up internally many times. in this carousel i ended up not using the scroll apis because of this side effect. setting block: none in the options would be great.