In Issue 6402, we resolved to add the scroll-related container queries.
These are four queries, two of which are closely related (do you have scrollable overflow, and how have you most recently scrolled) and apply to scroll container, the other two of which are just scroll-adjacent (are you a stuck stickpos, are you scroll-snapped) and apply to any element. @lilles original proposal was to add these as three separate container-type keywords: sticky, snap, and overflow, but a last-minute suggestion by @emilio to collapse them into a single scroll-state keyword was immediately agreed on with no real discussion:
<bramus> emilio: last minute q: do we need 3 different container types here?
<bramus> futhark: I think it makes sense given the current prototytping. only thing is i fyou want to select different ones you need to use names
<bramus> emilio: so we need 1 or 3?
<bramus> futhark: 1 makes sense
<miriam> +1 to a single container type, if it works technically
I think this decision was a mistake. Tying all three of these separate concepts to a single container type means that, by default, making it possible to query if an element is snapped will block the ability to ask about the overflow situation of the container it's snapped in. To get around this you have to give the containers names and include those in your query, which is somewhat odd; you normally only need to do that when multiple containers could answer your query but you want a specific one that's not the closest.
I think we should go back to having the stuck and snapped CQs depend on container-type: sticky or snap, instead.
In Issue 6402, we resolved to add the scroll-related container queries.
These are four queries, two of which are closely related (do you have scrollable overflow, and how have you most recently scrolled) and apply to scroll container, the other two of which are just scroll-adjacent (are you a stuck stickpos, are you scroll-snapped) and apply to any element. @lilles original proposal was to add these as three separate
container-typekeywords:sticky,snap, andoverflow, but a last-minute suggestion by @emilio to collapse them into a singlescroll-statekeyword was immediately agreed on with no real discussion:I think this decision was a mistake. Tying all three of these separate concepts to a single container type means that, by default, making it possible to query if an element is snapped will block the ability to ask about the overflow situation of the container it's snapped in. To get around this you have to give the containers names and include those in your query, which is somewhat odd; you normally only need to do that when multiple containers could answer your query but you want a specific one that's not the closest.
I think we should go back to having the
stuckandsnappedCQs depend oncontainer-type: stickyorsnap, instead.