Re: [csswg-drafts] Add scroll-direction state and updated overflowing state to scrollable in the explainer (#12130)

The design assumption here seems to be that the query only returns the direction of a *currently executing* scroll; once the scroll is done, it returns to "none". But I don't think that actually addresses the use-cases linked - the big one is making a header show fully at first, semi-hide when you start scrolling down so you have more space to read the page content, then reveal itself again when you scroll up.

This suggests that it needs to reflect the direction of *the current or most recent scroll operation*. If you scroll down and then stop scrolling and read for a bit, the author would want it to still reflect `down`, so the header stays semi-hidden. It would probably *never* return to `none`.

We should also make sure it does sufficiently solve this case. Like, the simplest code I could imagine an author using is:

```css
.header {
 translate: 0px;
 transition: translate 1s ease-in-out;
}
@container scroll-state(scroll-direction: down) {
 .header {
  translate: -50%;
 }
}
```

This would make the header reveal itself at first, and when the user starts scrolling up, but slide itself up (presumably into the unscrollable region) if they've been scrolling down.

--------

Another question - do we want to remember the scroll direction of each axis independently, or together? Like, given the code above, I suspect the author wants the header's shown/hidden state to care only about the most recent *block-axis* scroll; if the user scrolls sideways it shouldn't stop matching `down`. Are there use-cases for caring about the most recent scroll regardless of axis?

-------

The JS solutions for this sort of header-autohiding also often track the scroll a little - if the header is currently hidden, and you *start* scrolling up a little, it often doesn't immediately pop into fully showing, but rather just slides out a *little*, tracking with the amount of scroll until it's fully revealed. I don't think there's a clean way to do that with *just* this feature; that seems like a scroll-driven animation instead. But we should look into how that would be done, to make sure authors that want that feature don't still have to just go with a full-JS solution instead.

-- 
GitHub Notification of comment by tabatkins
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/pull/12130#issuecomment-2839534205 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Tuesday, 29 April 2025 16:33:01 UTC