[css-scroll-snap] [css-scroll-anchoring] Clarify the interaction between snapping and scroll anchoring

[emilio]

Intuitively it seems like snapping should win, but it is the kind of thing that should probably be in a spec? :-)

[tabatkins]

Yup, agreed. Hm, not sure which spec should define it - I think I lean to scroll-anchoring?

[argyleink]

I have a slide presentation frameworky thing I made that uses scroll snap and scroll anchoring (for deep links). I think it's a great use case and example space for the what and why of this issue. Find it here https://slyd.netlify.com/#natural-flow

[css-meeting-bot]

The CSS Working Group just discussed [css-scroll-snap] [css-scroll-anchoring] Clarify the interaction between snapping and scroll anchoring, and agreed to the following:

• RESOLVED: scroll-snap overrides scroll-anchoring for behavior heuristics

The full IRC log of that discussion

<dael> Topic: [css-scroll-snap] [css-scroll-anchoring] Clarify the interaction between snapping and scroll anchoring
<dael> github: https://github.com//issues/4830
<dael> Rossen_: Do we have a proposal? Who wants to introduce?
<dael> fantasai: I think this is a question of what wins between snapping and scroll-anchoring. I think scroll-snap wins. Not sure. I was looking for feedback from WG.
<dael> Rossen_: To make sure I got it, is the question which of the two prevails if I have scroll-snapping and scroll-anchoring?
<dael> fantasai: That's my interpretation. emilio filed it
<argyle> q+
<jensimmons> q-
<Rossen_> q?
<Rossen_> ack argyle
<dael> argyle: Updating a comment on the thread. Been building with scroll-snapping. Should target be similar to anchoring? Trying to clarify. Page wills croll to hash in URL?
<dael> smfr: Scroll-anchor is page maintain scroll position in face of content changes
<dael> argyle: So similar to scroll-snaping maintain position on resize and things like that.
<dael> smfr: yes
<dael> argyle: I guess I'm confused as to what this is trying to clarify.
<dael> smfr: Let's have emilio summarize
<dael> emilio: I filed this before we defined for layout to resnap. If we always resnap after layout I don't think there's an issue
<fantasai> emilio, resnapping was in the spec before you filed this :)
<dael> argyle: Have an issue where you refresh vs hit page first time what wins, target or scroll position. How many nested scrollers are restored. Sounds like this is more pointed then that case
<Rossen_> q
<dael> smfr: Question for emilio . What does snapping and anchoring have different ends states? If snapping is in place and scrolling you snap to something. Does scroll anchoring yank you away?
<dael> emilio: I guess ideally it shouldn't. I wonder if there are edge cases where scroll position is collapsed and so on
<dael> emilio: I could have added more details to the issue originally when this was in my head
<dael> Rossen_: Do we move on at this point? Sounds like there is no issue anymore
<dael> emilio: I'll try and look and reopen if I find something
<dael> Rossen_: Back to original question as to which overrides, snapping or anchoring. fantasai supposes snapping is favored over anchoring. Do we have this explicitly? If not it's good to be explicit so there's stable expectations for authors
<argyle> https://web.dev/snap-after-layout/
<dael> Rossen_: Are you suggesting this b/c we don't have it specified?
<argyle> https://drafts.csswg.org/css-scroll-snap-1/#re-snap
<dael> fantasai: Seems emilio got confused so might as well clarify
<dael> Rossen_: Anyone who believes we should favor anchor? Obj to scroll-snap overriding scroll-anchoring for behavior heuristics?
<dael> RESOLVED: scroll-snap overrides scroll-anchoring for behavior heuristics

[argyleink]

https://drafts.csswg.org/css-scroll-snap-1/#re-snap

[tabatkins]

All right, we've got text in Scroll Anchoring now that limits it only to valid snap positions when the scrollport is currently snapped. I've gone ahead and republished, as well.