[css-conditional] @container scroll-state(snapped) and snapchanged vs snapchanging

[lilles]

There are a few options for when the snap target changes for scroll-state(snapped: ...) queries

1. Matches same target as the snapchanged event
2. Matches same target as the snapchanging event
3. Introduce two different snapped feature names, one for each of (1) and (2)

If we only have a single feature, I assume (2) would be the preferred behavior?

If we decide to have two features, what should their names be? snapped and snapping?

[css-meeting-bot]

The CSS Working Group just discussed [css-conditional] @container scroll-state(snapped) and snapchanged vs snapchanging, and agreed to the following:

• RESOLVED: snapped matches snapchanging

The full IRC log of that discussion

<kbabbitt> futhark: this is an issue about scroll state snapped
<kbabbitt> ...question of whether state queries should match at the same time the snap changes or also including snap changing
<kbabbitt> ...think it makes sense to maek state query change while you're scorlling
<kbabbitt> ...got some feedback from ? that he thought you might want to have 2 separate queries
<TabAtkins> q+
<kbabbitt> ...one that changes with snap query and one that's only matching after ?
<flackr> q+
<kbabbitt> ...just looking for input, if someone thinks current behavior matching snap changing is good or if there are any other suggestions
<miriam> q+
<Rossen4> ack TabAtkins
<kbabbitt> TabAtkins: I agree that if we continue to keep just one query, having it match the snapchanging event so you'll start succeeding on the element that is becoming snapped is right
<kbabbitt> ...Adam's argument about having 2 is intriguing, would like to see an example
<kbabbitt> ...could easily be convinecd that it's a good thing to do
<kbabbitt> futhark: happy to resolve on matching snapchanging
<Rossen4> ack flackr
<kbabbitt> flackr: also agree that snapchanging is the right first step would like to see use cases for snapchanged
<flackr> https://github.com//issues/10838
<kbabbitt> ...also wanted to point out open issue about what snapchanging targets
<kbabbitt> ...10838
<kbabbitt> ...where I think, Adam has potentially requested a third possible query
<kbabbitt> futhark
<kbabbitt> futhark: just to correct a bit about what I have implemented so far
<kbabbitt> ...checking oth snapchanged and snapchanging
<kbabbitt> ...in case there's snapchanged that happened without snapchanging
<kbabbitt> flackr: that is not supposed to happen
<Rossen4> ack miriam
<kbabbitt> miriam: I think I basically agree with TabAtkins and flackr
<kbabbitt> ...to clarify, snapchanging is inclusive of ? changed
<kbabbitt> ...we're not saying it matches only when it's changing but also when it has changed
<kbabbitt> ...agree we're starting in the right way
<kbabbitt> Rossen4: other opinions?
<kbabbitt> futhark: currently snap... if that's a bad name, if we decide to add the scroll changed / snap changed later... [?]
<kbabbitt> flackr: are there other patterns we could follow
<kbabbitt> TabAtkins: I don't think we have precedent yet
<kbabbitt> miriam: I think snap is nice for the default
<kbabbitt> ...we can figure something else out for the other
<kbabbitt> futhark: we can just resolve that snapped matches snapchanging
<kbabbitt> Rossen4: other comments?
<kbabbitt> RESOLVED: snapped matches snapchanging
<TabAtkins> ScribeNick: TabAtkins

[lilles]

PR landed. There is also a test: https://wpt.fyi/results/css/css-conditional/container-queries/scroll-state-snapped-snap-changing.html