[css-sizing-4] aspect-ratio min-content size with % width

[cbiesinger]

https://drafts.csswg.org/css-sizing-4/#aspect-ratio

Usually, aspect-ratio is supposed to behave like a replaced element with that ratio. However, there is one behavior difference:

If a replaced element has a percentage width, the min-content size becomes 0:
https://source.chromium.org/chromium/chromium/src/+/master:third_party/blink/renderer/core/layout/layout_replaced.cc;l=912;drc=df8f58d9311eb29e65394e437a156b00fafc9a67;bpv=1;bpt=1

This is not the case with aspect-ratio, and when combined with contain-intrinsic-size this can lead to undesired effects, quoting from an email I got:

1. Go to https://dvoytenko.github.io/aspect-ratio-css/#x-intrinsic-and-float
2. Make the window smaller. Around innerWidth=300 you can see things pretty well.
3. Observe that both "Native", "Emulated" and "Images" sections are identical and things are as expected.
4. Now, in DevTools disable max-width: 100%; from .intrinsic-and-float .outer-cell {} rule.
5. Observe that all "Emulated" and "Images" are the same. But "Native" now expanded to the full size in the contain-intrinsic-size.

Should this behavior be spec'd for aspect-ratio?

@dvoytenko @bfgeek @fantasai

[dvoytenko]

Having consistency with replace elements (at least when contain: size; contain-intrinsic-size: _ _ are specified) would greatly simply adoption and would make specs more compatible with each other. So, I'd think this should be tried, unless there's a very strong reason not to do this.

[fantasai]

Whether an element is replaced or not is an independent question from whether it has an aspect ratio. Even if you have a replaced element without an aspect ratio, its min-content contribution still gets zeroed out by a percentage size or max-size.

Also, contain: size; contain-intrinsic-size: _ _ is not a switch for “behave like a replaced element”, it's a switch for “behave like you contain content of this size”.
So I think the spec's logic in not applying the special rule for min-content sizes makes sense...

That said, I can see why the “replaced element with percentage width has zero min-content size” rule is desired outside of replaced elements.

[fantasai]

Note, the spec for this special behavior is here: https://drafts.csswg.org/css-sizing-3/#replaced-percentage-min-contribution
It's currently defined to affect the min-content contribution but not the min-content size.

[tabatkins]

As in #5537, it would help a lot if I could understand what the desired behavior here was, and why. Right now I'm just looking at a series of testcases showing various behaviors, with no explanation of what's expected or desired and why.

It looks like @dvoytenko is trying to use these properties to make an element act like a replaced element. Is this right? If so, why?

It is def the case that c-i-s shouldn't have any relevance here; the behavior you get from contain:size and c-i-s should be identical to the behavior you get from a normal element with enough content to produce the same size. So this is purely a question about aspect-ratio.

[fantasai]

This might be a use case for the intrinsic-size property that was discussed earlier: specifically, for a value that sets the min-content size to zero. #4585

[tabatkins]

Yes, it seems very plausible that that's the control we want here.

[tabatkins]

So, our proposal is to a) close this issue no change b) describe the use case for zeroing out the min-content contribution in #4585 and try to solve by adding a new switch there.

@dvoytenko - does this sound reasonable to you? Would you mind posting an explanation of your use case in #4585?

[dvoytenko]

Not sure yet if this is the same as #4585. The demos that I made are the solutions I collected to build aspect ratio for different layouts in a pre-aspect-ratio world. What you see in the "Emulated" section are some very common solutions they are employed right now. I'm trying now to build the path from these "old" solutions to the new aspect ratio, which should help either with transition or possibly even shimming the aspect-ratio for non-supporting browsers. This issue is one discrepancy that I found. But I understand that this might not fit into the new specs - certainly, forcing the new properties to do something just for the backward compatibility is not a great idea. However, if this could be reconciled, it'd be a lot easier to shim old browsers that won't be supporting aspect-ratio for the next 1-2 years.

[cbiesinger]

Possible alternative solution in #5573

[fantasai]

@cbiesinger I think it would be better to go for a more generally-applicable solution in #4585, since that would solve similar cases even when contain is not being applied.