- From: CSS Meeting Bot via GitHub <sysbot+gh@w3.org>
- Date: Wed, 21 May 2025 16:42:40 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-ui][selectors][mediaqueries] Expose current scrolling direction`, and agreed to the following: * `RESOLVED: Working on scrolling queries` <details><summary>The full IRC log of that discussion</summary> <fantasai> TabAtkins: We have a whole batch of scroll-related container queries<br> <fantasai> TabAtkins: There are a lot of use cases in this space, particularly about knowing the last known scroll direction<br> <fantasai> TabAtkins: Two questions are: what's most recent scroll direction. Other is what is current scrolling direction.<br> <fantasai> TabAtkins: Hidey UI is like this on mobile<br> <fantasai> TabAtkins: Some discussion about velocity and other things that might be better to handle as scroll animations<br> <smfr> q+<br> <fantasai> TabAtkins: There's an explainer in the issue<br> <fantasai> smfr: In general this seems reasonable. Went through explainer, didn't see any explanation of rubber-banding<br> <fantasai> smfr: I don't think we want to expose that change in direction to web content<br> <fantasai> smfr: Also curious, what happens for scrolls that result from content changes<br> <fantasai> smfr: i.e. scrolls that scroll anchoring tries to prevent<br> <fantasai> smfr: Could end up with circularity, or oscillating between two states -- we see this often with JS-driven changes<br> <fantasai> TabAtkins: I think the answer should be that we base this on user-driven scrolling, so not script-driven or content-driven<br> <fantasai> TabAtkins: that would avoid these circularity issues<br> <flackr> +1<br> <Rossen8> ack smfr<br> <fantasai> TabAtkins: And it's close to impossible to detect in JS, could address directly this way<br> <fantasai> TabAtkins: Don't think there's a use case for script scrolling for these things<br> <fantasai> smfr: Seems surprising, because wouldn't an animated scroll to 0,0 want to show/hide these bars?<br> <fantasai> TabAtkins: possibly, but at that point you're scripting, so why not just script it<br> <flackr> I think at least scroll anchoring should not count, programmatic scrolling may be interesting<br> <fantasai> [missed]<br> <fantasai> Rossen8: what about autoscrolling?<br> <fantasai> TabAtkins: that's still scrolling<br> <ntim> q+<br> <fantasai> TabAtkins: Wanted to ask if group wants to pursue this idea<br> <fantasai> ntim: Not sure I'm convinced by answer that if we invoke script we can just invoke more script<br> <fantasai> ntim: The way you write the query is @container scroll-state(), and if you invoke script and you can't change that state, then you have to duplicate your CSS to support a class<br> <fantasai> ntim: And also have your scroll direction query<br> <fantasai> ntim: It would be duplicated into 2 places, if you invoke script to manipulate the state<br> <flackr> I think we can explore this with an example of how this would be done<br> <fantasai> TabAtkins: Question of what to do about script-driven scrolls is something to think more about, so let's discuss in the issues<br> <Rossen8> ack *<br> <Rossen8> ack ntim<br> <Rossen8> ack fantasai<br> <TabAtkins> fantasai: you don't necessarily have to introduce a class, could do it with a property<br> <TabAtkins> fantasai: and put that in the CQ<br> <flackr> q+<br> <fantasai> flackr: Directionally, should we consider whether "last scrolling direction" is thing we should pursue first, because it comes up in all use cases, and active scrolling direction can be pursued afterwards?<br> <fantasai> TabAtkins: Problems are easier and more common for recent scroll vs active scroll<br> <fantasai> flackr: Agree<br> <fantasai> flackr: Active scroll might need extra capabilities<br> <fantasai> Rossen8: any objections to this direction?<br> <TabAtkins> fantasai: We need to figure out what to do with active scroll, so we're designing a coherent syntax space fo rwhen it is tackled<br> <fantasai> RESOLVED: Working on scrolling queries<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-2898596305 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 21 May 2025 16:42:41 UTC