[csswg-drafts] Corner case in flex container intrinsic main size algorithm (#13928)

RichardTjokroutomo has just created a new issue for https://github.com/w3c/csswg-drafts:

== Corner case in flex container intrinsic main size algorithm ==
Hi, I was looking at CSSWG's [algorithm](https://drafts.csswg.org/css-flexbox-1/#intrinsic-main-sizes) on computing intrinsic main size, and I have what I believe to be a corner case to the algorithm.

Consider the following test case:

```html
<div style="max-width: 1px;">
    <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 
> 2. Place all [flex items](https://drafts.csswg.org/css-flexbox-1/#flex-item) 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](https://drafts.csswg.org/css-sizing-3/#min-content) [main size](https://drafts.csswg.org/css-flexbox-1/#main-size) of a [single-line](https://drafts.csswg.org/css-flexbox-1/#single-line-flex-container) flex container is calculated identically to the [max-content](https://drafts.csswg.org/css-sizing-3/#max-content) [main size](https://drafts.csswg.org/css-flexbox-1/#main-size), except that the [flex items](https://drafts.csswg.org/css-flexbox-1/#flex-item)’ [min-content contributions](https://drafts.csswg.org/css-flexbox-1/#intrinsic-item-contributions) are used instead of their [max-content contributions](https://drafts.csswg.org/css-flexbox-1/#intrinsic-item-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](https://wpt.fyi/results/css/css-flexbox/intrinsic-size/row-008.html?label=master&product=chrome%5Bexperimental%5D&product=edge%5Bexperimental%5D&product=firefox%5Bexperimental%5D&product=safari%5Bexperimental%5D) 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:
> 2. Place all [flex items](https://drafts.csswg.org/css-flexbox-1/#flex-item) 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.

Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13928 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 15 May 2026 07:15:58 UTC