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.