- From: Christian Schaefer via GitHub <sysbot+gh@w3.org>
- Date: Fri, 18 Nov 2022 08:29:29 +0000
- To: public-css-archive@w3.org
Schepp has just created a new issue for https://github.com/w3c/csswg-drafts: == [cssom-view] extend scrollIntoViewOptions' *ScrollLogicalPosition* with `"farthest"` and `"none"` == 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 or 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. Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/8098 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Friday, 18 November 2022 08:29:30 UTC