Re: [csswg-drafts] [css-ui][selectors][mediaqueries] Expose current scrolling direction (#6400)

The CSS Working Group just discussed `[css-ui][selectors][mediaqueries] Expose current scrolling direction`, and agreed to the following:

* `RESOLVED: Add scrolling direction to scroll-state queries, with the initial syntax in the explainer but issues open for bikeshedding`

<details><summary>The full IRC log of that discussion</summary>
&lt;emilio> astearns: we resolved to work on this, and then you moonira added it to the agenda<br>
&lt;emilio> moonira: main questions that were raised last time, what kind programmatic scrolls should affect these<br>
&lt;emilio> ... also the other question for relative / absolute scrolls we just discussed<br>
&lt;emilio> ... proposal is to solve these by adding direction state to scroll-state container query<br>
&lt;emilio> ... syntax is similar to scroll-state<br>
&lt;emilio> ... you can find the explainer<br>
&lt;emilio> ... active scrolling would be a separate future consideration<br>
&lt;emilio> q+<br>
&lt;emilio> ... any suggestions / questions?<br>
&lt;astearns> ack emilio<br>
&lt;ydaniv> emilio: I think in general sounds good<br>
&lt;ydaniv> ... wondering, what happens if you have someting scrollable or not based on direction?<br>
&lt;noamr> q+<br>
&lt;ydaniv> ... wondering whether it would make sense to store the scroll direction as part of the element, and not making associated as a scrolling box<br>
&lt;ydaniv> ... depending on whether it's a scroll container or not<br>
&lt;flackr> q+<br>
&lt;ydaniv> ... I think you can argue both ways<br>
&lt;ydaniv> noamr:  I think there's a similar issue in CQs<br>
&lt;ydaniv> ... the circular thing<br>
&lt;ydaniv> kizu:  you can change the size of your inner element that's styled<br>
&lt;ydaniv> andruud: you can through scroll timelines change someting that changes it<br>
&lt;ydaniv> ... I was thinking it's similar, we can solve this similarly<br>
&lt;ydaniv> ... we have stuck, that has the same problem<br>
&lt;ydaniv> emilio:  we have the stuck query that get stuck with the moving thing<br>
&lt;flackr> q-<br>
&lt;futhark> q+<br>
&lt;ydaniv> ... using the same mechanism makes sense to me<br>
&lt;ydaniv> andruud: I think it's in the explainer<br>
&lt;noamr> q-<br>
&lt;astearns> ack futhark<br>
&lt;emilio> futhark: sorry was out for a bit, but wanted to respond to the post-layout snapshotting<br>
&lt;astearns> https://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/scroll_state_explainer.md<br>
&lt;ydaniv> emilio: quetion was whether this part was part of the element itself or not<br>
&lt;ydaniv> ... andruud convinced me that it's same as the stuck thing<br>
&lt;emilio> futhark: so it depends on container-type<br>
&lt;moonira> http://github.com/w3c/csswg-drafts/blob/main/css-conditional-5/scroll_state_explainer.md<br>
&lt;emilio> andruud: but where's the last scroll direction stored<br>
&lt;emilio> futhark: I'd assume the post layout snapshotting mechanism?<br>
&lt;emilio> emilio: we should really define that properly<br>
&lt;emilio> futhark: yeah the HTML integration is missing, working on the implementation of that atm<br>
&lt;noamr> q+<br>
&lt;astearns> ack noamr<br>
&lt;emilio> ... will discuss where to put it in the html<br>
&lt;emilio> noamr: direction is unclear, is it scrolling direction or the scrollable direction?<br>
&lt;emilio> ... I'd use towards / along to distinguish these?<br>
&lt;emilio> ... something that clarifies what the value means?<br>
&lt;emilio> astearns: this is about scrolling towards<br>
&lt;emilio> emilio: do we support scrolling-along direction?<br>
&lt;emilio> noamr: yeah in the spec it's part of the same query<br>
&lt;emilio> emilio: yeah that's confusing<br>
&lt;ntim> +1 to noamr<br>
&lt;emilio> emilio: scrollable-direction vs. scrolling-direction maybe?<br>
&lt;emilio> ... but extra identifier also works I guess<br>
&lt;ydaniv> +1 to emilio<br>
&lt;ntim> q+<br>
&lt;astearns> ack ntim<br>
&lt;emilio> astearns: so everybody is good with adding scrolling direction?<br>
&lt;emilio> ntim: I'd like smfr to be here<br>
&lt;emilio> ... some questions about content changes<br>
&lt;emilio> emilio: I think same answer that my question<br>
&lt;emilio> flackr: yeah that came up in the last f2f<br>
&lt;emilio> ntim: other question was about rubber-banding, probably shouldn't be exposed<br>
&lt;emilio> flackr: agreed. Rubber banding in chrome doesn't change scroll offset but probably it shouldn't change the scroll direction even if it did<br>
&lt;ntim> scroll-state(direction: ...) / scroll-state(allowed: ) ?<br>
&lt;emilio> PROPOSAL: Add scrolling direction to scroll-state queries, with the initial syntax in the explainer but issues open for bikeshedding<br>
&lt;emilio> ntim: would like smfr to review<br>
&lt;emilio> astearns: fine taking the resolution?<br>
&lt;emilio> emilio: impl is the same as stuck and so on<br>
&lt;emilio> ntim: fine to resolve then<br>
&lt;emilio> RESOLVED: Add scrolling direction to scroll-state queries, with the initial syntax in the explainer but issues open for bikeshedding<br>
&lt;emilio> astearns: re programmatic scroll are we set with the previous issue?<br>
&lt;emilio> moonira: yes<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6400#issuecomment-3200664309 using your GitHub account


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

Received on Tuesday, 19 August 2025 13:00:36 UTC