[css-flexbox] New "Resolving Flexible Lengths" algorithm disagrees w/ old algorithm, when we go from negative free space to positive free space (even with flexibilities >= 1)

I ran across a case where the new "Resolving Flexible Lengths" algorithm
produces different (worse) behavior, as compared to the original
algorithm. This case has all flexibilities being >= 1, so per the "(No
change for a sum ≥ 1)" statement here...
  http://dev.w3.org/csswg/css-flexbox/#change-2012-flex-continuity
...this discrepancy is unexpected/undesirable.

The setup is fairly simple:
 - Fixed-size flex container (say, 100px wide) with 2 flex items.
 - Both items have a flex-grow & flex-shrink of 1, for simplicity.
 - First item has huge flex-basis (at least as large as container), and
a small max-main-size (say, 20px).
 - Second item has small flex-basis (say, 10px).

Live example:
  http://people.mozilla.org/~dholbert/tests/flexbox/flex-shrink-2.html

What *should* happen here (according to intuition & the old algorithm):
The first item should get clamped to its max-size, and the second item
should absorb the rest of the free space, filling up the container exactly.

What *actually* happens with the new "Resolving Flexible Lengths"
algorithm is that we *shrink* the second item, with no real need to do so.

Specifically, using step numbers from
http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths , here's
what happens:
 Steps 1 and 2: [ignoring, as they don't matter in this case]
 Step 3: We calculate free space, and get something negative.
 Step 4: We set the "originally desired free space" to something
negative, for both flex items.
 Step 5: Loop!
 - First loop: We freeze the first item at its (small) max-width.
 - Second loop:
  Step 5.1: yes, we can distribute space
  Step 5.2: We reset 2nd item to its (negative) orig desired free space.
  Step 5.3: We recalculate free space (and get a positive result).
  Step 5.4: Do nothing. (Free space is positive, and sum of desired free
spaces is negative [i.e. less than free space], which means we do nothing).
  Step 5.5: We set 2nd item's main size to its flex base size, plus its
(negative) desired free space.

And then we're done.

So we end up *shrinking* the second item, even though we end up with
plenty of free space and should be letting the second item absorb all of
that free space.

To handle cases like this, I suspect we'd need to allow the algorithm to
recompute the items' "originally desired free space" values during the
loop, under some restricted conditions (including "when the free space
changes sign").  Or something like that.

~Daniel

Received on Tuesday, 22 April 2014 23:39:01 UTC