Hi, I was looking at CSSWG's algorithm on computing intrinsic main size, and I have what I believe to be a corner case to the algorithm.
Consider the following test case:
<div style="max-width: 1ch;">
<span style="display: inline-flex; background-color: aqua;">
<span>A</span>
B C
</span>
</div>
In the above example, it is clear that shrinking must happen since the container can't contain both flex items. So the desired flex fraction for all flex items cannot be positive because again, shrinking must happen.
However, the first flex item <span>A</span> 's flex base size is 1ch (for simplicity let's use ch as unit). Since the minimum content size is also 1ch, the desired flex fraction is 0.
Since
- Place all flex items into lines of infinite length. Within each line, find the greatest (most positive) desired flex fraction among all the flex items. This is the line’s chosen flex fraction.
and
The min-content main size of a single-line flex container is calculated identically to the max-content main size, except that the flex items’ min-content contributions are used instead of their max-content contributions.
the chosen flex fraction will be 0. This will effectively "lock" all flex items to its original size (flex base size).
IMHO, this is a corner case (any scenario where at least one of the flex item's min content is the same as its flex base size) on the algorithm because shrinking should occur in this case to achieve better UI.
As an added note, I did some check and believe here is a relevant WPT test related to min size calculation. Chrome, Firefox, Edge, and Safari fail most of the subtests.
If the example above is indeed a corner case, I believe one possible fix would be creating two separate algorithm (one for max content and one for min content) for the following line:
- Place all flex items into lines of infinite length. Within each line, find the greatest (most positive) desired flex fraction among all the flex items. This is the line’s chosen flex fraction.
Hi, I was looking at CSSWG's algorithm on computing intrinsic main size, and I have what I believe to be a corner case to the algorithm.
Consider the following test case:
In the above example, it is clear that shrinking must happen since the container can't contain both flex items. So the desired flex fraction for all flex items cannot be positive because again, shrinking must happen.
However, the first flex item
<span>A</span>'s flex base size is1ch(for simplicity let's usechas unit). Since the minimum content size is also1ch, the desired flex fraction is 0.Since
and
the chosen flex fraction will be 0. This will effectively "lock" all flex items to its original size (flex base size).
IMHO, this is a corner case (any scenario where at least one of the flex item's min content is the same as its flex base size) on the algorithm because shrinking should occur in this case to achieve better UI.
As an added note, I did some check and believe here is a relevant WPT test related to min size calculation. Chrome, Firefox, Edge, and Safari fail most of the subtests.
If the example above is indeed a corner case, I believe one possible fix would be creating two separate algorithm (one for max content and one for min content) for the following line: