[css-anchor-position] `anchor-size()` should fallback to `auto`, not zero

[fantasai]

I think by default the anchor-size() function in the sizing properties should

• compute to auto on elements to which it doesn't apply (i.e. non-absolutely-positioned boxes)
• fall back to auto otherwise

Falling back to zero is almost never what you want here.

[xiaochengh]

What happens when it's used in a calc, like width: calc(anchor-size(--bad-ref width) + 20px)?

[tabatkins]

More specifically, it should trigger the "behaves as auto" behavior that things like cyclic percentages do.

[xiaochengh]

What happens when it's used in a calc, like width: calc(anchor-size(--bad-ref width) + 20px)?

I found the answer myself. calc-size(auto) works here.

(I was away for a few months and missed so much progress...)

More specifically, it should trigger the "behaves as auto" behavior that things like cyclic percentages do.

It's a bit different from my mental model that a calc() should always keep going (like division-by-zero becomes infinity), and invalid values are resolved only at the top level.

Or are there existing examples where a calc() can be invalidated as long as part of it is invalid, in case I missed something?

[tabatkins]

Yes, the behavior I'm describing (turning the whole value into "behaves as auto") is already what happens with cyclic percentages. width: calc(20% + 20px) will turn into auto if the parent's size is indeterminate.

[andruud]

What is the computed value of width:calc(anchor-size(--bad-ref width) + 20px)? Keeping in mind that anchor-size() now resolves at computed-value time.

[chrishtr]

What is the computed value of width:calc(anchor-size(--bad-ref width) + 20px)? Keeping in mind that anchor-size() now resolves at computed-value time.

Tab explained it to me offline. The computed value will be a "simplified form" of the specified value, and the used value will be auto. I.e., the effect on layout will be the same as if the author had used width:auto instead.

[tabatkins]

Yeah, the anchor() reference would just remain unresolved (similar to how layout-dependent %s are left unresolved in the computed value of a calc()). And then the whole value would "behave as auto" during layout, identical to cyclic percentages.

[andruud]

That is very annoying. We removed the capability of representing anchor*() past computed-value time, this would then be the only reason why that is needed again. But I don't have a better proposal given the circumstances.

@tabatkins Can auto be specified explicitly by the author, or is that triggered only when no fallback is present?

[tabatkins]

No fallback is the way to specify "this should behave as auto if it fails", yeah.

[andruud]

Is "behaves as auto" only for width/height? What about min-width/height? And what about max-width/height (does not support auto).

Yeah, the anchor() reference would just remain unresolved [on the computed value]

Do we gain anything from this vs. coercing the computed value into auto?

[andruud]

Actually, can we just make the bad situations invalid at computed-value time?

[tabatkins]

We're suggesting the "behaves as auto" just to have consistency with cyclic percentages, which didn't coerce the computed value to auto for Reasons. I don't have any particular reason to prefer one way or another, tho.

Actually, can we just make the bad situations invalid at computed-value time?

Hm, there's a thought! I... think that would be okay? It seems within the remit of that concept.

[andruud]

Actually, can we just make the bad situations invalid at computed-value time?

Hm, there's a thought! I... think that would be okay? It seems within the remit of that concept.

Then I think we should do that instead of "behaves as auto". Because:

• We should generally resolve things at the value stage where we have enough information to resolve that thing.
• It's consistent with the regular behavior of anchor*() resolving computed-value time (interleaving). For percentages-in-sizing, surviving computed-value time is business as usual. Not so for anchor-size(). It would only happen in this error case.
• We automatically get reasonable behavior for the property in question, also for future properties. ("Behaves as auto" does not work for max-*, which doesn't accept auto).
• The rendering pipeline after style does not need to know or care about the behavior. It makes it possible to deal with this problem more locally.

---

Regardless of the chosen approach, it would be good to clarify if the behavior should also apply to anchor(), or if that should stick with a 0px fallback.