-
Notifications
You must be signed in to change notification settings - Fork 715
[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
Comments
CC @kizu |
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. |
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 A potential option that might make the single inset case ignore |
The CSS Working Group just discussed
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 |
Consider an element inside a 100x100 containing block:
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?
The text was updated successfully, but these errors were encountered: