Re: [csswg-drafts] [css-position][css-anchor-position][css-align] anchor-center and overflowing the inset-modified containing block (#12020)

The CSS Working Group just discussed `[css-position][css-anchor-position][css-align] anchor-center and overflowing the inset-modified containing block`, and agreed to the following:

* `RESOLVED: anchor-center alignment is constrained by IMCB, similar to other alignments`

<details><summary>The full IRC log of that discussion</summary>
&lt;TabAtkins> fantasai: when you have an anchor-center alignment, and you're using insets, the insets reduce the space you have available to you.<br>
&lt;TabAtkins> fantasai: normally you'd align inside that reduced rectangle and overflow when you're too big<br>
&lt;TabAtkins> fantasai: we have rules now that say, by default, you can overflow your IMCB until you overflow your original CB<br>
&lt;TabAtkins> fantasai: anchor-center has the behavior that you can overflow the IMCB even when it's smaller than the IMCB<br>
&lt;TabAtkins> fantasai: [drawing example on the whiteboard]<br>
&lt;TabAtkins> fantasai: i have a big CB. The anchor is small and near the edge.<br>
&lt;TabAtkins> fantasai: on my abpos, I set `inset: 25px` (which is further than the anchor's distance from the CB edge)<br>
&lt;TabAtkins> fantasai: with left/right/center alignment, it's aligned inside the IMCB<br>
&lt;TabAtkins> fantasai: but anchor-center's desired alignment is centered right on the anchor. But the anchor is in the no-go zone (outside the IMCB)<br>
&lt;TabAtkins> fantasai: chrome positions the abspos outside the IMCB (even tho it could fit in there) becuase it asks to be on the anchor<br>
&lt;TabAtkins> fantasai: I'm arguing the author gave us insets, they're asking to stay inside this region. so we should honor that.<br>
&lt;TabAtkins> fantasai: anchor-center should be as close as it *can* be to the ideal position, but should stay in the IMCB until it actually overflows.<br>
&lt;TabAtkins> iank_: even if it's overflowing - that gets complex but we can push it to the side temporarily<br>
&lt;fantasai> TabAtkins: shift off of center but stay as close as you can is what happens if abspos is big enough to overflow CB, it will break center alignment to stay within CB but stay close enough<br>
&lt;fantasai> TabAtkins: our impl doens't do that for the IMCB, just the CB<br>
&lt;fantasai> TabAtkins: I don't recall if this was intentional or not<br>
&lt;fantasai> iank_: My initial recollection was that prioritizing anchoring, centering on the anchor, was desirable until you hit the original CB<br>
&lt;fantasai> iank_: so that's I interpreted the note in the spec<br>
&lt;fantasai> iank_: I'm fine with changing this, but I worry that we might get... people might be setting insets to reduce available space, for example<br>
&lt;fantasai> iank_: that's a side-effect that happens here<br>
&lt;fantasai> iank_: so I worry we might get some bug reports<br>
&lt;fantasai> iank_: "not actually on my anchor"<br>
&lt;fantasai> iank_: I'm not sure<br>
&lt;astearns> ack kizu<br>
&lt;fantasai> kizu: I would prefer to stay in the IMCB as long as possible<br>
&lt;fantasai> kizu: basically I agree with Elika<br>
&lt;fantasai> iank_: if we go with that, what happens when the anchored element is larger than the IMCB<br>
&lt;fantasai> iank_: It'll stay locked to one side if IMCB<br>
&lt;fantasai> TabAtkins: I think it should try to grow towards centering on the anchor<br>
&lt;fantasai> iank_: My concern with that is that it creates a jump<br>
&lt;fantasai> iank_: typically want to be continuous<br>
&lt;fantasai> TabAtkins, fantasai: no jump<br>
&lt;fantasai> TabAtkins: as it grows it says as close as it can be to anchor while in the IMCB<br>
&lt;fantasai> TabAtkins: as growing past IMCB, keeps growing in the direction that puts closer to anchor-center ideal<br>
&lt;fantasai> TabAtkins: If as wide as CB, fills it.<br>
&lt;fantasai> TabAtkins: if wider, grows in direction towards anchor<br>
&lt;fantasai> TabAtkins: once it hits the edge, then starts growing towards end side<br>
&lt;fantasai> [Tab draws this]<br>
&lt;fantasai> iank_: So potentially 3 direction changes that could occur<br>
&lt;fantasai> fantasai: I believe this is what I hav implemented in webkit<br>
&lt;fantasai> astearns: compat concerns?<br>
&lt;fantasai> iank_: Not particularly<br>
&lt;fantasai> iank_: I can try behind a flag and see what happens<br>
&lt;TabAtkins> (actually there's four potential direction changes. it might reach its ideal position before it touches the original CB edge<br>
&lt;TabAtkins> )<br>
&lt;fantasai> iank_: I think changing center thing is more<br>
&lt;fantasai> iank_: but the tests will be tricky because of the 3 direction changes that can occur<br>
&lt;fantasai> iank_: But I think the spec does need to be clarified<br>
&lt;fantasai> TabAtkins: Happy to get that clarified<br>
&lt;fantasai> PROPOSED: anchor-center alignment is constrained by IMCB, similar to other alignments<br>
&lt;fantasai> astearns: Further comments or questions?<br>
&lt;fantasai> astearns: Any objections?<br>
&lt;fantasai> RESOLVED: anchor-center alignment is constrained by IMCB, similar to other alignments<br>
</details>


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


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

Received on Thursday, 3 April 2025 18:21:33 UTC