[css-anchor-position] should alignment safety consider the containing block?

[fantasai]

Alignment has a concept of "safety", which is, we try to bias alignment in a direction that won't result in clipping the content. For unsafe centering, we don't care; but for safe centering we overflow away from the unscrollable region.

For anchor positioning (and absolute positioning in general to be fair), there's two containers that are of interest: the inset-modified containing block, and the actual containing block.

Should the default behavior and/or the safe behavior of an overflowing alignment bias towards staying within the containing block if possible, before finally overflowing the end/end edges?

[fantasai]

Proposal here is:

• When unsafe, do unsafe alignment into the inset-modified containing block. (No change)
• When safe, overflow the IMCB in the "safe" direction. (No change)
• By default, do unsafe overflow of the IMCB, but safe overflow of the CB.
  I.e. as you grow:
  1. Align within the IMCB as specified.
  2. If as you grow you overflow the IMCB, keep aligning as specified.
  3. If as you grow you reach the edge of the CB, don't overflow that edge, grow in the other direction.
  4. If as you grow you overflow the CB, do safe alignment (overflow away from the unscrollable region).

[tabatkins]

+1 to this proposal. There's definitely still use-cases for shifting within the IMCB, but I agree that most of the time it's the CB you're concerned with.

[bfgeek]

I suspect that anything changing default alignment won't be web-compatible given how long folks have been relying on abspos layout.

[tabatkins]

Yeah, I'm definitely comfortable with keeping the legacy behavior (aka skipping iii in the list) for normal alignment, and possibly even for start/center/end. It's really only important for anchor-center.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] should alignment safety consider the containing block?, and agreed to the following:

• RESOLVED: Accept proposal in 10316 but don't change normal behavior when not using inset-area

The full IRC log of that discussion

<keithamus> fantasai: this is a fun one, tackles two issues. Both anchor-center currently defined to changed the size, as well as to shift the alignment.
<keithamus> ... so, the proposal is to remove the special sizing behavior from anchor-center. When neither unsafe nor safe is specified in the alignment property - in other words by default. And only when its not normal
<keithamus> ... when the object is larger than the container we overflow away from the scrollable region
<fantasai> https://github.com//issues/10316#issuecomment-2125437844
<keithamus> fantasai: So you're using the inset properties to create a containing block. If you're in abspos is small enough to fit in the IMCB you just do alignment as you specify
<keithamus> ... If its larger than the IMCB we don't make it start aligned. If you hit the edge, say the right edge, the point were it's big enough to break out of the containing block we overflow in the opposite direction
<keithamus> ... we overflow away from the scrollable region
<keithamus> ... what this does - it gets you a very nice behavior for anchor center
<TabAtkins> q+
<keithamus> ... that you keep the item visible. Try to center as much as possible but don't overflow unless you overflow the entire containing block
<keithamus> ... shift the area as much as you can
<fantasai> https://github.com//issues/10315
<keithamus> ... the other issue is this one
<iank_> q+
<keithamus> ... a nice illustration somewhere
<fantasai> https://github.com//issues/9960#issuecomment-1944518084
<keithamus> ... Una made a nice example of this
<keithamus> ... the second behavior, not the one that resizes
<Rossen4> ack TabAtkins
<keithamus> TabAtkins: the only thing is you can't apply to normal. So locked in on compat. We might try to not do this on start/center/end
<keithamus> ... there's large amounts of content that applies center to abspos things
<keithamus> ... we might need to disallow on those based on compat
<keithamus> ... we'll see how it goes when we deploy
<keithamus> iank_: a little concerned web devs will get confused
<keithamus> ... they say anchor center and the CB for some reason or another is small... I guess we might just have to teach webdevs to use unsafe anchor center
<keithamus> ... which probably isn't the worst
<Rossen4> ack iank_
<keithamus> ... but be prepared for likely recommending that heavily
<keithamus> TabAtkins: if you have a weirdly small CB the position try stuff will be affected to. So they'll have to learn
<keithamus> fantasai: the behavior we ideally wanted is you do safe centering if you're overflowing the edge of the scroll container
<keithamus> ... but nobody has implemented that subtlety.
<keithamus> iank_: that is long sailed
<keithamus> ... means you invalidate a bunch of engine optimisations
<keithamus> fantasai: but if we think people will want unsafe align for CBs not in viewport we could do that
<Rossen4> ack fantasai
<keithamus> ... probably a good starting point
<fantasai> s/probably/but this is probably/
<keithamus> iank_: The problem with that is you'll need some way to expose magical default for those cases
<keithamus> ... if we go down that path you'll need some magic alignment like overflow alignment
<keithamus> ... I'm fine with this proposal but I suspect we might... people might be reaching for unsafe more.
<keithamus> ... we should be cognizant that we might need to recommend it a lot more.
<keithamus> Rossen4: any other opinions?
<keithamus> PROPOSED: Accept proposal in 10316 but don't change normal behaviour when not using inset-area
<keithamus> s/PROPOSED/fantasai: PROPOSED:/
<keithamus> RESOLVED: Accept proposal in 10316 but don't change normal behavior when not using inset-area
<TabAtkins> So with this, I think Bikeshed's dfn panel behavior is just `inset-area: bottom span-right;` and *nothing else*