[css-flexbox] Resolving Flexible Lengths loop-step 4 needs to handle 0 free space

Hi Tab,

I think I found a bug in the Resolving Flexible Lengths spec-language.

The problem is that Section 9.7 step 5 substep 4 currently does nothing,
if the [recalculated] free space is 0. (It says what to do if the free
space is positive or negative, but not 0.)

I *think* it should make us set all the flex items' "desired free space"
values to 0 there.

Spec reference:
 http://dev.w3.org/csswg/css-flexbox/#resolve-flexible-lengths

MORE DETAILS / HOW THIS CAUSES PROBLEMS:
========================================
Right now, if we end up with 0 free space in the second loop iteration
(say, because we gave away all of the original free space on the first
loop-iteration, to satisfy a min violation), then we'll end up doing the
wrong thing. What happens is:
 - Loop step 2 resets any unfrozen items' "desired free space" to their
"original desired free space" (which is nonzero, if the flex item is
flexible).
 - Loop step 3 recalculates free space (and discovers that it's 0).
 - Loop step 4 *wants* to normalize the items' "desired free space"
values based on the current free space available, but it has us do
nothing, because it doesn't call for anything to be done when the free
space is 0. So the "desired free space" values are left unchanged (at
their nonzero values).
 - Loop step 5 gives each unfrozen flex item its (nonzero!!) desired
free space, to add to its flex base size.  This is effectively
distributing free space that is *no longer available for distribution*.

And this ends up making the flex items overflow the container.

FIX:
====
I *think* we can address this by adding this at the end of Loop step 4:
  # Otherwise, if the free space is zero, set each
  # non-frozen flex item's desired free space to zero.

(Alternately, we could merge this into the existing positive-free-space
case [making it a >=0 case], but that would require some
language-massaging, since there's currently prose about "maintaining ...
magnitudes relative to each other", which is meaningless when we're
setting everything to 0.)

Thanks,
~Daniel

Received on Thursday, 10 April 2014 23:51:13 UTC