W3C home > Mailing lists > Public > www-style@w3.org > January 2014

[css-flexbox] Typo in new "Resolving Flexible Lengths" text ('hypothetical main size' in step 5 substep 4)

From: Daniel Holbert <dholbert@mozilla.com>
Date: Wed, 29 Jan 2014 17:16:22 -0800
Message-ID: <52E9A7E6.9050507@mozilla.com>
To: www-style <www-style@w3.org>
Hi Tab,

I've been reviewing the new "Resolving Flexible Lengths" text, here:
http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths
...and I noticed what I think is a minor bug in the new algorithm.

Specifically: In Step 5(loop) substep 4, for "Adjust main size", it
currently says:
 # Add each item's desired free space to its hypothetical main size.

Instead of "hypothetical main size" there, I think it *wants* to say
"flex base size". (Note that the former takes min/max-clamping into
account; the latter does not.)

This is important because the 'free space' (and the 'desired free space'
values) are calculated by subtracting *flex base sizes* from the flex
container's size (up in step 3, before the loop), so when we divvy up
the free space, we should still be doing it with respect to *flex base
sizes*, or we might hand out too much free space.

For example, we run into trouble with cases like e.g.
 <div style="display:flex; width: 100px">
   <div style="min-width: 90px; flex: 1 20px"></div>
 </div>

The expected result there would be for the child to end up with a
main-size of 100px (flexing to use all of the container's space).

But I believe the new spec-text would make the child 170px there.
Specifically, it'd have us do the following (line-numbers correspond to
steps in section 9.7):
 (1) Decide to use flex-grow factor
 (2) (nothing; we have no items w/ flex factor of 0)
 (3) Free Space = 100px - 20px = 80px
 (4) Original Desired Free Space = 80px * 1 = 80px
 (5) Enter Loop:
   (1) (nothing; we have unfrozen items, so proceed)
   (2) Desired Free Space = 80px
   (3) (nothing; no normalization required.)
   (4) Main Size = 90px + 80px = 170px
         ( hypothetical main size + desired free space )
   (5) (nothing; no min/max violations)
   (6) Total violation = 0; exit the algorithm.

So we end up sizing the child to 170px, when it should really be 100px.


If we instead make the change I'm suggesting (use flex base size in step
4, inside the loop) then those last 3 steps would instead look like this:
   (4) Main Size = 20px + 80px = 100px
         ( flex base size + desired free space )
   (5) (nothing; no min/max violations)
   (6) Total violation = 0; exit the algorithm.
...and we'd end up with the child having the correct main size (100px,
exactly filling the container).

Thanks! Let me know if I'm missing something.
~Daniel
Received on Thursday, 30 January 2014 01:16:50 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:08:39 UTC