[css-sizing-4] Should aspect-ratio apply for width: auto; height: auto;?

[cbiesinger]

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

With width: auto; height: auto; aspect-ratio: 1/1; (in a horizontal writing mode), we still have a definite width, should we use that to calculate a height using the aspect ratio? Or should we require width: 100%;?

/cc @bfgeek @fantasai @tabatkins

[cbiesinger]

Similar question for height: auto on a stretched row flex item, where this still gets a definite height.

[AmeliaBR]

I would expect all sizing for elements with a fixed aspect-ratio to behave the same as for a replaced element with a fixed aspect ratio.

For a block element in flow layout, that means that yes, the block size would be maximized to fit (after adjusting for padding/border, same as normal), and then the aspect ratio would determine the height. In other layout situations, different calculations would apply, but I think we now have defined algorithms for all these cases, including the flexbox one (if I recall correctly: it stretches to fit the row height, then the width gets calculated from the aspect ratio & becomes the flex-basis, but then flex grow or shrink applies and can distort the aspect ratio from its ideal).

The main difference between a CSS box with aspect ratio, versus an image or SVG with an aspect ratio, would be in how min-content and max-content sizes are calculated, based on the normal rules for text/child CSS content instead of based on the intrinsic sizes of the replaced content.

[fantasai]

Yes, in the auto/auto case we do calculate the block size against the inline size using the aspect ratio. As @AmeliaBR points out, this is already defined because we had to define it for SVGs with an intrinsic aspect ratio and no intrinsic size, and aspect-ratio defines itself as applying those rules.

The box’s automatic sizes are calculated the same as for a replaced element with an intrinsic aspect ratio and no intrinsic dimension in that axis, see e.g. CSS2 § 10 and CSS Flexible Box Model Level 1 § 9.2.

(If there's particular layout algorithms which don't handle this case, it needs a separate issue, since the problem applies to both such images as well as boxes with aspect-ratio.)

[fantasai]

Closing the issue, since I think the spec already defines this and there's nothing to do here.

[cbiesinger]

@AmeliaBR So, I want to follow up on the flex item case. First I thought you were right, now I'm not sure. See:
https://drafts.csswg.org/css-flexbox/#definite-sizes step 3
"Once the cross size of a flex line has been determined, the cross sizes of items in auto-sized flex containers are also considered definite" (emphasis mine)

But https://drafts.csswg.org/css-flexbox/#algo-main-item happens before the cross-size determination.

As such, I think the flex item case does require a height: 100% to trigger aspect-ratio in this case.

[cbiesinger]

Testcase, if it helps: http://plexode.com/eval3/#s=aekVQXANJVQMbAx1yAXgePQN5GwFHTUZZHAGDnRIREVGiAZofPU+vAQGVl5kDQlRRRkRVDlNCVUpQphASo4udSFNGRk8crR0Qcq6wT9HTA14A

[AmeliaBR]

@cbiesinger Are you only looking in Chrome? Because there is still cross browser inconsistency here. Chrome collapses elements to zero, Firefox does not, see modified version of your test case with SVG elements as well.

@fantasai would probably remember better than I, but I'm pretty sure the WG consensus was that the “elements with aspect ratio but no defined size collapse to zero in flexbox” was a bad thing. 😏 If you want to work on tracking down the necessary tests & bug fixes, that would be greatly appreciated!

Either way, the CSS box with aspect-ratio should behave the same as the SVG.

[cbiesinger]

@AmeliaBR I wasn't particularly talking about any specific browser, only about the spec.

So which part of the spec makes that work? I see that in Firefox the SVG will have a width even with align-self: flex-start and that makes no sense at all:

https://plexode.com/eval3/#s=aekVQXANJVQMbAx1yAXgePQN5GwFHTUZZHAGDnRIREVGiAVBWVU1KT0adhwFTRkWjgp0TE6mreg5URk1HnZ+hwlVCU1Ucmh89TwEBHVGXmQOEnVFWU1GgAYxVVbjQNUZUVbFIHRBR0dPVlpiaQlRRRkRVDlNCdZQUwQCSjRadJC3IxPUalAKnCIGCYWZ4DD7uOTxaiVbD2fD6fj+gECggBgwBLTEJpQLEUiwQjDSjRUK5IAJXJRGLAjKBZbIOCQBn4BCdDTUcAcmIZNKxGhimVERibQmLUapEJRTIjhKbZCVGI5KJpNbJRWJMTQQjLVCEzJFqDttm04nU8n1AoVECdGetITpQfxPJFNqbyq1YrRGW1dr9hsaaIrMJgzcwDtNUd1teMXD4DLwA

cc @dholbert

[AmeliaBR]

Some relevant past issues & discussion:

Resolution in #951 (comment) says “Replaced elements with only an intrinsic aspect ratio has a min-content size of 0” but see also #694 about clarifying the flexbox spec.

The current relevant spec text is in the Flex Layout Algorithm:

If the flex item has ...

• an intrinsic aspect ratio,
• a used flex basis of content, and
• a definite cross size,

then the flex base size is calculated from its used inner cross size and the flex item’s intrinsic aspect ratio.

I think if you follow all the linked definitions for terms, that says the Firefox behavior is correct. Note that the stretch value for align-items isn't relevant: because the cross-size is definite (a single-row flexbox with defined height), that gets used to determine the cross size of the box with an aspect ratio and no other size constraints.

[cbiesinger]

You convinced me for the align-self: stretch case, but I don't see why that's the case for non-stretched items? dholbert/fantasai, any thoughts?