[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.

[tabatkins]

Looking at the "bound width and height" example, the markup is real confusing because it's using abspos on the element to make it fill the parent (and the interaction between abspos with non-auto insets and aspect-ratio, it turns out, isn't well-defined; the Position and Sizing specs both try to define the automatic sizes), but if I unset all of those properties...

I can end up with an empty block element, with a set aspect-ratio (say, 1/1) and min-width/min-height:100%, laid out into a container with a set width and height. Since both width and height are auto, width is the ratio-determining dimension, and height is the ratio-dependent dimension. Because it's a block element, it expands to the width of its container, then tries to apply its 1/1 ratio to make the height the same size, but that gets limited by the max-height:100%, thus breaking the aspect-ratio.

The bug here is that sizing constraints are meant to transfer across the ratio as well; search for "Additionally, sizing constraints in either axis" in https://drafts.csswg.org/css-sizing-4/#aspect-ratio. This means the max-height:100%, resolving to a smaller length, should transfer across the 1/1 ratio to become a max-width constraint as well, which would prevent the element from growing to the full width of its container; instead, it'll stay a perfect square.

[dvoytenko]

@tabatkins to confirm: right now the bound width/height is working correctly in Chrome. Are you saying it shouldn't?

[tabatkins]

Right now, the behavior in Chrome is what I described above: an element with aspect-ratio: 1/1; max-width: 100%; max-height: 100% in a wide parent will break its aspect-ratio, filling the parent entirely rather than remaining square. That's broken; it should remain square.

[tabatkins]

Ah, what I'm describing is the behavior of Chrome 85. In Chrome 87 (per Dima), things are fixed to act like how I described they should per spec: the elements don't fill the entire parent, and instead shrink to maintain their aspect-ratio while respecting the max-* constraints. Yay!

[fantasai]

Closing this out under the concept that aspect-ratio is not “behave like a replaced element in all aspects”, just “behave like you have an aspect ratio”. As explained in #5549 (comment), the zeroing out of the min-content size is a replaced element characteristic, not an aspect-ratio characteristic, and applies even to replaced elements that have no aspect ratio. Therefore tying this behavior into the application of aspect-ratio is inappropriate. If we want a switch for “zero out min-content size”, that's issue #4585.