[css-flexbox] Resolving Flexible Lengths algorithm currently allows the "flex-shrink" value of a min-size-clamped flex item to impact other items' sizing

Hi Tab,

I think I've run across some unintended behavior in the new
"resolving flexible lengths" algorithm, regarding flex-shrink when
min-width/min-height clamping comes into play.

TL;DR: Right now, immediately-frozen flex items' flex-shrink values can
end up influencing the sizing of other flex items, which doesn't make
sense to me. I think we should perhaps change the Resolving Flexible
Lengths algorithm to do some sort of re-normalization of flex-shrink
factors (and possibly recompute the "original desired free space"?) on
each iteration of the "Loop:" step, to correct this.

PREMISE
=======
Stepping back, here's a basic premise that I'll assert, which the
current algorithm violates (as I'll show below):

  Premise: If an element's flex base size is equal to its
  min main size (meaning that it can't actually shrink),
  then *its flex-shrink value should not affect layout at all*.

I believe this premise holds in the old algorithm, and it also holds for
flex-grow on flex items that are clamped by their max-main-size.

But it's violated in some cases for flex-shrink with the spec's current
algorithm.

(Is this premise something that we want to honor?  Personally, I think
it is a reasonable expectation, but it's possible I'm expecting too much.)

Anyway, assuming my premise is valid: now I'll show how the current spec
violates this premise.

THE PROBLEM:
============
Basically, the problem arises from these facts:
 (a) The flex-shrink value of a given element can impact the "original
desired free space" calculation for other elements, *even when the sum
of the flex-shrink values is less than 1*, due to the way flex-shrink
factors are scaled/renormalized. (Note that this isn't true of flex-grow
values that sum to less than 1, which makes this not a problem for
flex-grow.)

 (b) We lock in the "original desired free space" calculation for all
items, before we discover any min/max-size violations.

 (c) We still use this locked-in "original desired free space" for
giving out [negative] free space to unfrozen items, after we've frozen
other flex items.

So, the problem is that we calculate each item's "originally desired
free space", and then we discover that one item needs to be frozen, and
then for the remaining items, we *still* use their "original desired
free space" values as the [negative] free space that they take, even
though these values were calculated under the assumption that the frozen
element would be taking some of the [negative] free space.

EXAMPLE:
========
Here's a testcase which demonstrates this, including a screenshot of how
it renders in Firefox with the new resolving flexible widths algorithm:
  http://people.mozilla.org/~dholbert/tests/flexbox/flex-shrink-1.html

ADDRESSING THIS:
================
Assuming we want to fix this, I think we'd need to renormalize the
flex-shrink values on each loop iteration. Or something like that.

Thanks, & apologies for the long email. Please let me know if I should
elaborate on any part. I'll think a bit more about what exactly needs to
be done to address this, but I wanted to get the problem out there first.

~Daniel

Received on Friday, 18 April 2014 17:45:14 UTC