Skip to content

[css-position][css-anchor-position][css-align] anchor-center and overflowing the inset-modified containing block #12020

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
fantasai opened this issue Mar 28, 2025 · 5 comments

Comments

@fantasai
Copy link
Collaborator

Consider an element inside a 100x100 containing block:

.abspos {
  position: absolute;
  position-anchor: --foo;
  inset: 20px;
  place-self: anchor-center;
  size: 8px;
}

Suppose the anchor is positioned at 20px from the left. Centering it against the anchor would place its left edge at 16px, but the inset is 20px. What should happen here?

This question came up in web-platform-tests/interop#945

My interpretation is that the default overflow rules should only allow the item to overflow its insets if it doesn't fit within its inset-modified containing block. Ian's was that anchor-center simply ignores the insets always. What do we think is the right behavior?

@fantasai
Copy link
Collaborator Author

CC @kizu

@kizu
Copy link
Member

kizu commented Mar 30, 2025

Mm, I think I'd prefer it to stay inside the designated inset area as long as possible. One practical case where you could want to take the inset into account: to use it as to define a “dead area” where you don't want the element to go into, for example if there is some sidebar with useful stuff that you don't want to overlap. Example: https://codepen.io/kizu/pen/LEYgKwY — in Chrome right now it does overlap the sidebar area.

@bfgeek
Copy link

bfgeek commented Mar 31, 2025

From playing with this when I was first implementing IMO you want to ignore the IMCB, and instead apply the safety to the CB. You typically want to stay anchored to the center of the anchor as long as possible, otherwise it looks like the implementation is broken when it isn't. E.g. if you place it in bottom center its quite common for the anchor to overflow.

A potential option that might make the single inset case ignore anchor-center ?

@css-meeting-bot
Copy link
Member

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

@kbabbitt
Copy link
Collaborator

kbabbitt commented Apr 3, 2025

The diagram drawn during discussion:

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Thursday Afternoon
Development

No branches or pull requests

5 participants