Re: [csswg-drafts] [css-anchor-position-1] Define precisely when anchor recalc points happen, and which offsets it captures. (#12371)

The CSS Working Group just discussed `[css-anchor-position-1] Define precisely when anchor recalc points happen, and which offsets it captures.`.

<details><summary>The full IRC log of that discussion</summary>
&lt;fantasai> TabAtkins: We have a concept in anchor positioning where we can't always track the exact position of the anchor, because if it is in different scrolling context then that can get janky<br>
&lt;fantasai> TabAtkins: So we define specific points in time when we do go and look for the actual scroll offsets to get accurate positions for layout<br>
&lt;fantasai> TabAtkins: We remember those, and if you scroll after that, you lose the connection<br>
&lt;fantasai> TabAtkins: There's one spot that Emilio thought should add, a recalculation point, is when your anchor references change.<br>
&lt;fantasai> TabAtkins: Agree that's a missing point<br>
&lt;fantasai> TabAtkins: If there's more here, I would agree with Emilio, but at the minimum we should add anchor reference changing as a scroll recalculation point<br>
&lt;fantasai> astearns: Further question on whether you need to recalc when the layout changes.<br>
&lt;fantasai> TabAtkins: That should be implicit in the spec already... only scroll positions that we don't live-respond to<br>
&lt;TabAtkins> fantasai: I think my q is should we be defining this in the opposite dirction?<br>
&lt;TabAtkins> fantasai: so we say what we don't pay attention to (scrolling) rather than what we do (several things)<br>
&lt;TabAtkins> fantasai: lots of things to include that you might want to respond to. mainly we just want to say that it doesn't respond to scrolling.<br>
&lt;TabAtkins> fantasai: if you change the layout of the anchor itself, that recalcs the anchor box - positioned element might need to resize, etc.<br>
&lt;TabAtkins> fantasai: if the CB changes, etc.<br>
&lt;TabAtkins> fantasai: I'm assuming all of these things make it become invalid, otherwise your layout wont' make sense<br>
&lt;fantasai> TabAtkins: Layout changes are definitely intended to already be captured live. If spec doesn't make that clear, I'll clarify<br>
&lt;astearns> ack fantasai<br>
&lt;fantasai> TabAtkins: I can consider flipping the definition, but do what to be careful about what we require things to do.<br>
&lt;fantasai> TabAtkins: Right now allow list where you definitely remember changes is a good approach... but a lot of the things you listed should be implied.<br>
&lt;fantasai> TabAtkins: but can take a resolution on that and make sure spec reflects it<br>
&lt;fantasai> fantasai: So what are the exceptions that you don't do relayout for?<br>
&lt;fantasai> TabAtkins: You don't respond to scroll positions, except as defined where you refresh those anchors.<br>
&lt;fantasai> TabAtkins: Layout refreshes everything. Should invalidate everything. But as long as layout isn't changing, we should only respond to scrolling at particular spots as defined.<br>
&lt;fantasai> fantasai: [explains why the spec is confusion]<br>
&lt;fantasai> TabAtkins: Ok, sounds like I should clarify the spec.<br>
&lt;fantasai> PROPOSED: Anchor positioned boxes recalculate layout for all changes that might affect their size/position except scrolling except for special recalculation points.<br>
&lt;fantasai> TabAtkins: Need to think about it a bit, but I think that's probably right.<br>
&lt;fantasai> TabAtkins: Let's come back if anything more than editorial changes is needed.<br>
</details>


-- 
GitHub Notification of comment by css-meeting-bot
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12371#issuecomment-3160840200 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Wednesday, 6 August 2025 16:34:36 UTC