[css-flexbox-1] Section 9.7(3) – Remove redundant criterion

[gitspeaks]

The spec currently states:

3. Size inflexible items. Freeze, setting its target main size to its hypothetical main size…

• any item that has a flex factor of zero
• if using the flex grow factor: any item that has a flex base size greater than its hypothetical main size
• if using the flex shrink factor: any item that has a flex base size smaller than its hypothetical main size

Proposal: Remove the line:

"any item that has a flex factor of zero"

This condition is redundant and does not impact the algorithm’s logic or behavior. An item may have a flex-grow of 0 and a flex-shrink of ≥1 (or vice versa), but what actually matters in this step is whether the item will participate in growth or shrinkage based on the direction of the flexing and the relationship between its flex base size and its hypothetical main size.

The two remaining conditions already fully capture which items are inflexible in this context. The explicit mention of a flex factor of zero adds no operational value and may even be misleading.

[gitspeaks]

Also, consider freezing flex items that have a flex factor of zero corresponding to the direction of flexing, as follows:

• If using the flex grow factor: freeze any item whose flex base size is greater than its hypothetical main size, or whose flex-grow value is 0.

• If using the flex shrink factor: freeze any item whose flex base size is smaller than its hypothetical main size, or whose flex-shrink value is 0.

[Loirooriol]

How is it redundant? Dropping it would make the algorithm ill-defined in the "using the flex grow factor" case, because this ratio could be degenerate:

For every unfrozen item on the line, find the ratio of the item’s flex grow factor to the sum of the flex grow factors of all unfrozen items on the line.

Sure, the algorithm is already ill-defined in the "using the flex shrink factor" case (#8928), but that doesn't justify making it worse.

[gitspeaks]

How is it redundant? Dropping it would make the algorithm ill-defined in the "using the flex grow factor" case, because this ratio could be degenerate:

That’s a separate issue that needs its own appropriate rule. Applying “any item that has a flex factor of zero” freezes any time when flex-grow or flex-shrink is 0.

Freezing an item solely based on whether flex-grow or flex-shrink is 0 without considering the flexing direction doesn’t make sense.

[Loirooriol]

It's not a separate issue if now it's good (one of the cases, at least) and after your change it will be bad.

I don't get what you are saying about the flex direction.

[gitspeaks]

if now it's good. (one of the cases, at least)

I argue now it's practically bad in the majority of cases.

Example:

<div style="display: flex; width: 500px; font-family: Arial; outline: red solid;">
  <div>
    Lorem ipsum dolor sit amet consectetur adipisicing elit. Itaque, vitae? Recusandae porro eveniet sapiente placeat magnam enim fugit provident, numquam vero ducimus minus iusto ullam aliquam. Labore, optio? Recusandae nesciunt voluptatem reiciendis deserunt voluptates quod nostrum aperiam ad eius similique explicabo quasi placeat aliquam cumque laboriosam qui animi hic voluptatum, iusto nemo molestiae possimus deleniti dolorum! Quae laboriosam ratione deleniti corporis facere temporibus adipisci, illo doloribus? Maxime sed dicta soluta animi nesciunt saepe eum. Excepturi nam enim numquam ipsam placeat praesentium, optio eligendi natus odit quo sunt nobis quisquam tempora molestias explicabo eveniet est nulla magnam maxime! Optio, maiores temporibus.
  </div>
  <img src="box.jpg" alt="box" style="width: 50%;" />
</div>

Both items have flex-grow: 0, so they fall under the condition: “any item that has a flex factor of zero,” which means they should be frozen.

Obviously, that’s not what happens—and not what’s expected either.

[gitspeaks]

I don't get what you are saying about the flex direction.

I’m saying that a flex factor of zero should correspond to the direction of flexing.

So if we’re shrinking—because the flex line is larger than the container—and some items have flex-shrink: 0, then it makes sense to freeze those at step 3, doesn’t it?

[Loirooriol]

which means they should be frozen.

No it doesn't. You are ignoring:

Determine the used flex factor. Sum the outer hypothetical main sizes of all items on the line. If the sum is less than the flex container’s inner main size, use the flex grow factor for the rest of this algorithm; otherwise, use the flex shrink factor.

direction of flexing

This is what the spec is already doing. Without using a term that you invented without defining it, and which can be confused with flex-direction.

[gitspeaks]

I'm not ignoring anything. The condition "any item that has a flex factor of zero" is a blanket rule that ends up breaking most layouts. I genuinely don’t understand how you’re not seeing this, especially considering the example above where everything freezes at that point — regardless of whether it's in the “otherwise, use the flex shrink factor” case.

Without using a term that you invented without defining

I didn’t invent any term. When items shrink, it implies a direction of flexing. Either way, I was very clear in my proposal:

• If using the flex grow factor: freeze any item whose flex base size is greater than its hypothetical main size, or whose flex-grow value is 0.
• If using the flex shrink factor: freeze any item whose flex base size is smaller than its hypothetical main size, or whose flex-shrink value is 0.

[gitspeaks]

I think I understand what the intent was:

• 9.7(1): Determine the used flex factor. Sum the outer hypothetical main sizes of all items on the line. If the sum is less than the flex container’s inner main size, use the flex grow factor for the rest of this algorithm; otherwise, use the flex shrink factor.

• 9.7(3): Any item that has a flex factor of zero.

In other words:

9.7(1) used flex factor == 9.7(3) flex factor

So at the very least, I would expect 9.7(3) to say:

“Any item where the used flex factor is zero”

That said, I think this kind of indirect wording is completely unnecessary. I’m not even sure “used” is appropriate in this context, since as I understand it, "used" refers to the final value of a property, not the chosen property. There’s no need to get into all of this when it could just be stated explicitly, as I proposed.

Also, 9.7(1) should simply say: "Determine which flex factor to use" rather than "Determine the used flex factor"

[Loirooriol]

"Used" is an English word, it's not part of the term, there is no property called flex-factor so it's clearly not https://drafts.csswg.org/css-cascade-5/#used-value.

And I don't understand why you keep pointing at 9.7(3). The entire 9.7 refers to the flex factor multiple times, all of these instances are the flex factor determined in 9.7(1).

Even if you got confused by "used flex factor", the spec literally says "use the flex grow factor for the rest of this algorithm" so I just don't get how you can interpret that in any other way.

[gitspeaks]

"Used" is an English word, it's not part of the term, there is no property called flex-factor so it's clearly not https://drafts.csswg.org/css-cascade-5/#used-value.

One could also interpret "used" here as the used value of a "factor property" (i.e., either flex-grow or flex-shrink). That ambiguity is exactly the problem — it shouldn't be open to interpretation in the first place.

And I don't understand why you keep pointing at 9.7(3). The entire 9.7 refers to the flex factor multiple times, all of these instances are the flex factor determined in 9.7(1).

Aside from 9.7(3), the term "flex factor" is used twice, every other mention explicitly names "flex shrink factor" or "flex grow factor". The context in 9.7(5)(c), in particular, make it very clear about which "flex factor" is being referenced.

Even if you got confused by "used flex factor", the spec literally says "use the flex grow factor for the rest of this algorithm" so I just don't get how you can interpret that in any other way.

That’s just not accurate.

What the spec actually says is:

use the flex grow factor for the rest of this algorithm; otherwise, use the flex shrink factor.

And even then, the wording is unnecessarily tricky. It doesn’t really accomplish anything, since the rest of the section explicitly refers to either the "flex grow factor" or the "flex shrink factor" most of the time anyway. So using the term "flex factor" without additional context just adds confusion — which is exactly the point I’ve been trying to make.