You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following algorithm describes how the two properties influence the used value of the height property:
The tentative used height is calculated (without min-height and max-height) following the rules under "Calculating heights and margins" above.
If this tentative height is greater than max-height, the rules are applied again, but this time using the value of max-height as the computed value for height.
If the resulting height is smaller than min-height, the rules are applied again, but this time using the value of min-height as the computed value for height.
In your initial example, it seems that the height: 10px is only a tentative value in the presence of min-height: min-content, so it’s not completely clear whether the flex line sizing should be based on the tentative or the adjusted height. In fact, following 10.7, it reads as though min-height must be considered before finalizing the height, suggesting that recomputing based on the intrinsic size (and ending up at 50px) is actually expected behavior.
Take the following example:
https://www.software.hixie.ch/utilities/js/live-dom-viewer/?saved=13717
The initial block-size of the flexbox is
10px
. Because this is a single line, the flex-line size becomes 10px, and hence thats the intrinsic-size.As per:
https://drafts.csswg.org/css-flexbox-1/#algo-cross-line
In Blink we had a unintentional bug where we'd re-compute the block-size with the intrinsic size of the line. (Resulting in 50px in the line above).
However this bug does provide a better behaviour.
Note we have compat on a very simlar case wrt. aspect-ratio:
E.g. the min-height is intrinsic, and we all recompute the initial block-size based on this.
The text was updated successfully, but these errors were encountered: