[css-anchor-position] Alignment shouldn't interfere with sizing

[fantasai]

The current definition of anchor-center says

Additionally, any auto inset properties resolve to 0. However, the available space for the positioned element in the relevant axis is reduced to the size of the largest rectangle that is centered on the default anchor element and doesn’t overflow the inset-modified containing block. (Possibly being zero-sized, if the anchor’s center is not within the inset-modified containing block.)

In general, alignment doesn't change the containing block for sizing, it just shifts the box within the alignment container. (The only exception is stretch, which simply fills the box.) In all cases, there are only two sizes to consider, and their relationship to each other: the alignment container, and the alignment subject. I don't think we should change that here.

Also this behavior yields some really weird, and likely unexpected, results for simple things like

inset-area: bottom;
max-width: 20em;

where if the anchor happens to be near the edge of the screen, the tooltip ends up wrapped into a very very narrow tall block.

If the author wants to cap the size to the largest width that could result in true centering, let's add that as a keyword to the sizing or inset properties or something else that's actually supposed to affect sizing.

[tabatkins]

Yes, this sizing behavior was very intentional, and necessary for reasonable behavior, even if it can result in a too-small containing block size sometimes.

Note that sizing and alignment are strictly in that order - size first, then align. In every other alignment keyword, that's fine - if you size into the full containing block size (and don't overflow right away), you can then left, right, or center yourself and you'll always stay within the containing block. This isn't true for anchor-center - if you size into the full width of the containing block, and then center on the anchor, it's very easy to overflow the rect. Here’s an example.

There are two solutions to this. The first is what the spec currently says - give it the sizing constraint that actually keeps it within the containing block rect when it's centered on the anchor.

The second is to give it the full size, but then un-align it if necessary to keep it in the containing block rect. This is the "slide" behavior we've talked about, and intentionally deferred so it can get more design thought. (See #9960) We want sliding for more than just anchor-center (I mention wanting anchor-left and anchor-right - Bikeshed's own dfn panels use JS to get an "anchor-left" behavior with sliding.)

When we design the sliding behavior more generally, it should override this containing block size reduction for anchor-center, and let you size as large as you want. But before then, it's better to be too small in some cases than overflow (possibly into the unscrollable area) in even more cases.

[fantasai]

The sliding behavior is what alignment does, fundamentally. I think that should be the default. Tweaking the available space is not what alignment does, generally, and I don't think it's an appropriate default here. If you want to tweak sizing, you should use a property that affects sizing.

[css-meeting-bot]

The CSS Working Group just discussed [css-anchor-position] Alignment shouldn't interfere with sizing.

The full IRC log of that discussion

<emilio> fantasai: the current anchor-center definition changes the avail size for sizing the abspos to the largest rect that can be centered wrt the anchor that fits within its inset area
<emilio> ... so if your anchor is in the center on the screen you have all the regular stuff
<TabAtkins> q+
<emilio> ... but if you're in the edge of the screen you have a little bit of space
<emilio> ... alignment never affects the avail space
<emilio> ... this would be a first
<iank_> q+
<emilio> ... alignment takes the box and avail space and alings it
<emilio> ... I think that's what we should do for anchor-center
<emilio> ... if the author wants to resize the anchor we should provide keywords in the inset or what not properties to enable that
<astearns> ack TabAtkins
<emilio> ... so I think the anchor-center kw should say "size the box in this container, and move it as close to the desired alignment without overflowing the container"
<emilio> TabAtkins: this is novel for alignment
<emilio> ... but that's not needed for existing alignment values
<emilio> ... this isn't true for anchor-center
<emilio> ... if half your size is larger than the distance to the closer edge
<emilio> ... then you overflow if you stay centered
<emilio> ... in particular if you fill the cb then you're almost guaranteed to overflow
<emilio> fantasai: that's not what I'm proposing tho
<emilio> TabAtkins: right, two posibilities
<emilio> ... (1) is the current behavior
<emilio> ... which has this edge case but looks good pretty good if you're in the middle
<emilio> ... looks better than growing to the full size and align
<emilio> ... (2) is what you suggest
<emilio> ... this was what the spec originally said
<emilio> ... but the sliding behavior needs to be available to more than anchor-center
<emilio> ... bikeshed does this for left-aligned anchors for example
<emilio> ... but whatever you do it can't be locked to anchor-center
<emilio> ... when we come up with something that does the sliding, it should disable this shrink-avail-size bit
<fantasai> una made a visual of this issue in https://github.com//issues/9960#issuecomment-1944518084
<emilio> ... so I wrote the spec the way it is because it looks better in the majority of cases
<emilio> ... you can kinda fix this with min-size (though it's not perfect because you'd overflow)
<emilio> ... but when we have the sliding bit then it should work just fine
<astearns> ack iank_
<emilio> ... if we do the sliding I'm concerned about doing it too early before knowing what it'd look more generally
<emilio> iank_: we do have changing of avail space in inset-{axis}: auto in rtl
<emilio> ... there are cases where this happens
<astearns> ack fantasai
<emilio> fantasai: yeah static pos...
<emilio> ... I see what your concern is
<emilio> ... there's another issue I filed that should get us there
<emilio> ... I feel strongly that alignment should not change sizing
<emilio> ... my suggestion is that maybe we defer this issue, we have a chat about the other issue
<emilio> ... if we have a system that works then we can come back to this issue
<emilio> ... I'd much rather give authors control about this
<emilio> TabAtkins: what's the other issue?
<emilio> fantasai: #10316
<kizu> +1 to fantasai that align should not resize things, I had cases in my experiments where this behavior was not what I wanted, and I almost would always prefer sliding behavior (which _sounds_ like something close to how `position: sticky` could work)
<emilio> TabAtkins: happy with that
<emilio> ... there are slight tricks we could do to minimize the
<emilio> ... bad case here
<emilio> ... but we can chat
<emilio> astearns: let's leave open and come back after TabAtkins and fantasai have discussed the other one
<TabAtkins> ah yeah i haven't seen 10316 yet, cool