W3C home > Mailing lists > Public > www-style@w3.org > March 2012

[css3-flexbox] min/max need to be swapped in step 6 of "resolve the flexible lengths"

From: Daniel Holbert <dholbert@mozilla.com>
Date: Fri, 09 Mar 2012 12:26:49 -0800
Message-ID: <4F5A6789.7070406@mozilla.com>
To: www-style <www-style@w3.org>
CC: Alex Mogilevsky <alexmog@microsoft.com>, "Tab Atkins Jr." <jackalmage@gmail.com>
Hi www-style,

I think the current Flexbox Layout Algorithm has some words reversed 
right now, in such a way that it'd never terminate if it were to be 
implemented as-written.

It currently says:
4. Distribute free space proportional to flex
5. Fix min/max violations:
     1. Adjust each flexible item for min/max.
     2. If the size has changed, it is a violation.
     3. The violation may be positive (min violation) or
        negative (max violation). Accumulate the difference.

6. If the sum of all violations is:
   Zero:     Exit the algorithm.
   Positive: Freeze items with max violations, and return to step 2.
   Negative: Freeze items with min violations, and return to step 2.

TL;DR; I think min/max are reversed in step 6 there.

Suppose we're in a situation with two flexbox items, both flex:1 0 0px, 
and we have plenty of extra space to distribute.  One of our items is 
constrained by a max-width. (and that's the only min/max limit in play)

Suppose there's enough free space that we violate the item's max-width 
in Step 4.

So -- when we hit Step 5, we'll reduce that item's size to match its 
max-width.  This is a "negative (max violation)" according to 5.3 above.

That was the only violation -- so in step 6, the sum of all violations 
is negative.

Given that, step 6 says we should "Freeze items with min violations..." 
(uh oh, we didn't have any of those!) "...and return to step 2".

So we don't freeze anything, and we'll repeat the exact same steps and 
we'll hit the exact same violation over & over again, looping forever.

If we swap "min" and "max" in step 6, then I think it makes sense & 

Received on Friday, 9 March 2012 20:27:18 UTC

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