Add scroll-direction state and updated overflowing state to scrollable in the explainer

[tursunova]

[css-conditional-5] Explainer for the proposal in #6400 (comment).

[lilles]

However, in this approach, if a user was still pressing on the scrollbar after scrolling to the specific direction the scroll-direction would be considered as none since the scrollbar wasn't moving anymore.

This sentence has an assumption about when the scroll direction is updated that is not described in this doc.

Nit: "scrolling to the specific direction" -> "scrolling in the specific direction"

[tursunova]

Added open questions with options about when scroll-direction should be none.

[tabatkins]

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:

.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? If there are, maybe we can let an author opt into that with another keyword, like scroll-direction: down most-recent, so that the simpler version scroll-direction: down can just care about the direction of the most recent scroll in that 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.

[tursunova]

Thanks @tabatkins , this makes sense. Then few open questions with this approach:

• Since now the value reflects the most recent scroll in that direction, value none becomes unreachable expect of the initial state, should we leave it then or should we remove it? If we decide to remove none:

1. We can have inline-start and block-start as initial values.
2. Values X, Y, block and inline will always match, so there would be no point of having them.
3. if we have latin script and only vertical scroller, should we match inline-start initially?

• As far as I understood, if we want to match the most recent scroll direction (not none) once we stop scrolling, then the value reflects the most recent scroll in that direction, e.g. if we scrolled down and then right, scroll-direction: bottom will still match after scrolling right. But then is there a use case when we want to hide/show some vertical scrolling specific content once we start scrolling horizontally? Then we might have 2 values, let's say bottom and latest-bottom, where one will still match after scrolling horizontally and another will only match if latest scrolling (not latest vertical scrolling) was bottom.

[yisibl]

Are there use-cases for caring about the most recent scroll regardless of axis? If there are, maybe we can let an author opt into that with another keyword, like scroll-direction: down most-recent, so that the simpler version scroll-direction: down can just care about the direction of the most recent scroll in that axis.

The examples in @bramus' article have a lot of use cases that only care about the recent scroll direction.

• https://codepen.io/bramus/pen/oNJeLWg
• https://codepen.io/bramus/pen/wvRqVBm

[bramus]

The examples in @bramus' article have a lot of use cases that only care about the recent scroll direction.

But there’s also demos that depend the last-non-none direction. The “Hidey Bar” is the typical example for this, which Tab also mentioned.

In https://brm.us/hidey-bar I figured out how to “remember” the last-non-none direction: by (ab)using an infinite transition-delay on the custom prop that stores the direction – as documented in the explainer that is part of this PR.

Would be nice/handy if this “remember“ option were built into the API. Some ideas:

1. Perhaps we distinguish between scroll-direction and active-scroll-direction?

• active-scroll-direction represents the active scroll direction. If you stop scrolling, it becomes none again.
• scroll-direction starts as none but once you scroll it remembers the last active scroll direction that is not none.

2. More values? E.g. idle-after-down

Personal preference for 1 – seems more easy for authors.

---

Another question - do we want to remember the scroll direction of each axis independently, or together?

Good question. I see one use cases for scroll-based games that allow you to control a character walking in a 8-directional movement (cardinal directions + diagonals), which would rely on remembering each axis independently.

• More values such as down-right?
• More scroll-direction variants? i.e. (active-)(vertical|horizontal)-scroll-direction

But you could ask yourself if that’s a common enough use-case to tackle …