Add @container scroll-state(direction) to [css-conditional-5]

[argyleink]

It's common for developers to write a small bit of javascript to observe the scroll direction and derive a boolean state of whether it's progressing or regressing. This is useful for flipping the direction of say, a duck walking across the bottom of the screen (this one doesn't turn around, showing the issue) or for showy/hidey navigation bars (a very popular pattern).

There's even Bramus who's written about how to derive the scroll direction using some tricky custom property timings in combination with scroll driven animation. Here's Bramus solving the duck so it turns around and walks back instead of moonwalking, but requires Canary at the moment.

I'd like to propose that directionality is added to the Scroll State Query feature. It would make this trivial.

.scroll-container {
  container-type: scroll-state;
  overflow: auto;
  
  nav.sticky {
    @container scroll-state(direction: forward) {
      visibility: hidden;
    }

    @container scroll-state(direction: backward) {
      visibility: visible;
    }
  }
}

This example shows how a scroller can hide a sticky nav while scrolling down/forward, and show it when scrolling up/backwards. Folks could easily use CSS transforms and transitions to animate this instead of the simplified show/hide in the example snippet.

I am proposing forward and backward here as the keywords, but am open to suggestions, and also haven't accounted for a scroller that works on both axes. Maybe they should be down, up, left and right?

Relevant spec: https://drafts.csswg.org/css-conditional-5/#scroll-state-container

[hvanops]

@flackr also suggested a default value in the cases where no scroll is happening. For example, when the user first lands on the page or if they are just reading something and not moving the scrollbar.
Rob- feel free to add to or correct my understanding.

[argyleink]

where no scroll is happening

sounds like another proposal for a scroll-state query!? since it's binary; is it scrolling currently, or not. could compose it then with other queries too. but maybe abstracting the concept of moving or not is more tied with the direction than i'm thinking.

[smfr]

Would this apply for programmatic scrolls (scrollTo(), and those triggered by layout changes)? If so, I worry about circularity.

[bramus]

Duplicate of #6400?

[argyleink]

closing in favor of #6400!