Ambiguity in Documentation: scoll state queries and scroll snap events.

[LukeAtlas22]

MDN URL

https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_conditional_rules/Container_scroll-state_queries

What specific section or headline is this issue about?

Types of container scroll-state query - snapped

What information was incorrect, unhelpful, or incomplete?

snapped: Queries whether a container is, or will be, snapped to a scroll snap container ancestor along a given axis.

This statement lets infer that is possible to do two types of snapped query, one corresponding to the event scrollsnapchange, and the other corresponding to the event scrollsnapchanging.

But then it says:

Evaluation will occur when the scrollsnapchanging event fires on the scroll snap container.

What did you expect to see?

Change the first statement, or add (if exist) a way to do a scroll state query on the firing of the scrollsnapchange event.

Do you have any supporting links, references, or citations?

No response

Do you have anything more you want to share?

No response

MDN metadata

Page report details

• Folder: en-us/web/css/css_conditional_rules/container_scroll-state_queries
• MDN URL: https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_conditional_rules/Container_scroll-state_queries
• GitHub URL: https://github.com/mdn/content/blob/main/files/en-us/web/css/css_conditional_rules/container_scroll-state_queries/index.md
• Last commit: e9b6cd1
• Document last modified: 2025-04-10T14:56:07.000Z

[chrisdavidmills]

@LukeAtlas22 hi there, and thanks for posting this issue. I'm sorry that you found this ambiguous.

There is only one type of snapped container scroll state query. The relevant @container block tests whether a new scroll snap target has been snapped to, and if so, applies the contained rule(s) to the scroll snapped target's selected children.

It just so happens that the test will occur, and the browser will evaluate which new scroll snap target has been snapped to, when the scrollsnapchanging event fires on the scroll snap container.

If you wanted to, you could use JavaScript to update the styling when the scrollsnapchanging event fires, but the snapped container scroll state query provides a much easier way to do so, using CSS.

I hope this helps to clarify.

This being the case, what do you think we should update in the article, to remove the ambiguity?

[LukeAtlas22]

@chrisdavidmills Hi Chris, and thank you for your response.
Here is a more precise explanation of the ambiguity I encountered, along with a proposal to improve the documentation concerning the snapped query:

The difference between the scrollsnapchange and scrollsnapchanging events is that scrollsnapchange occurs only when the element is stably snapped at the center of the scroller—therefore, it only happens when the element is snapped. On the other hand, scrollsnapchanging occurs when scrolling towards an element is detected—so the element is being snap-changed.

These two distinctions, in my opinion, correspond to:

• scrollsnapchange – The element is snapped
• scrollsnapchanging – The element will be snapped

Therefore, also in my view, it is not accurate to say:
"Queries whether a container is, or will be, snapped" — these are two very different conditions, especially within carousels where elements are positioned far apart and only one is visible while others are hidden.

A more precise phrasing would be:
"Queries whether a container is going to be snapped".

[chrisdavidmills]

These two distinctions, in my opinion, correspond to:

* scrollsnapchange – The element is snapped

* scrollsnapchanging – The element will be snapped

Therefore, also in my view, it is not accurate to say: "Queries whether a container is, or will be, snapped" — these are two very different conditions, especially within carousels where elements are positioned far apart and only one is visible while others are hidden.

A more precise phrasing would be: "Queries whether a container is going to be snapped".

@LukeAtlas22 ah, of course, there are two events! I'd forgotten about that. Sorry, it has been a while since I last looked at this stuff ;-)

Yes, your proposal for removing the ambiguity sounds simple and effective. I will open a PR to fix this; I'll make sure to catch all the potential instances on different pages.