[csswg-drafts] [css-flexbox] Undefined target main size in Resolving Flexible Lengths (#5179)

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

== [css-flexbox] Undefined target main size in Resolving Flexible Lengths ==
A few related questions about and potential bugs in the Resolving Flexible Lengths algorithm https://drafts.csswg.org/css-flexbox/#resolve-flexible-lengths

Background from step 1: here we decide whether to use flex grow factors or flex shrink factors. It’s always one or the other. It’s never neither.

Background from step 2: this step introduces a new concept: a *target main size* for flex items. This step gives it a value for each inflexible item. For other items however this value is **undefined** at this point.

Background from step 4.c.: it is marked up as a definition list with four entries like this:

> <dl>
>     <dt>If the remaining free space is zero</dt>
>     <dd>Do nothing.</dd>
>     <dt>If using the flex grow factor</dt>
>     <dd>[…]</dd>
>     <dt>If using the flex shrink factor</dt>
>     <dd>[…]</dd>
>     <dt>Otherwise</dt>
>     <dd>Do nothing.</dd>
> </dl>

**Issue 1**: In step 4.c., under “If using the flex grow factor”: this paragraph talks about “the item”, but at this point of the algorithm we are not considering any given item. So, which one? It looks like this paragraph should start with “For every unfrozen item on the line,” like the next one.

**Issue 2**: The control flow of the algorithm in step 4.c. is not at all clear to me. How do the four entries of the definition list relate to each other? Is each iteration of the loop only supposed to go through one of them? In that case maybe entries 2 and 3 should start with “Otherwise,” to indicate that? If that’s not the case and each entry is independent and to be considered sequentially, then the first entry accomplishes nothing and could be removed. Since we’re always using one of the grow or shrink factor, the fourth entry looks like accomplishes nothing either way and could also be removed. But presumably the editors had a reason to include it, so I feel I’m missing something.

**Issue 3**: Depending on the resolution of issue 2, the target main size may (if remaining free space is zero) still be undefined for some items by the time we get to step 4.d. of the algorithm, although that step relies on the target main size of all non-frozen items. Similarly, step 5 wants a defined target main size for all items. Should there be a new step after step 2 that initializes the target main size of unfrozen items to their flex base size?

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

Received on Saturday, 6 June 2020 09:14:37 UTC