[css-flexbox] "scaled flex shrink factor" is it scaled by *inner* or *outer* flex base size?

Hi Tab & fantasai,

I just ran across a possible bug in Gecko & Blink, where they disagree
with the flexbox spec -- but I think it might really be a spec bug, & I
wanted to clarify it here before proceeding with a Gecko patch.

The spec text in question is:
   # For every unfrozen item on the line, multiply its
   # flex shrink factor by its outer flex base size,
   # and note this as its scaled flex shrink factor.
http://dev.w3.org/csswg/css-flexbox/#scaled-flex-shrink-factor

I'm interested in the word "outer" here.  With that word, the spec is
saying that an item's margin/border/padding (henceforth "MBP") should be
included in the flex-shrink-factor scaling calculation.

Firstly, here's a testcase to show what browsers actually do:
http://people.mozilla.org/~dholbert/tests/flexbox/compat_tests/scaled-flex-shrink-with-margin-1.html

As shown by that testcase, IE11 scales by the outer flex base size
(matching the spec), while Firefox & Chrome scale by the *inner* flex
base size.

The specced behavior seems wrong to me -- I think we should drop the
word "outer" there (leaving us with the "inner" flex base size).

Here's my thinking:
 (1) In a flex item, the part that's *actually* flexible is its *content
box* -- not its MBP. The flexbox algorithm doesn't grow or shrink the
MBP (ignoring auto margins, since they don't come into play here).  Flex
items with larger content boxes really *do* have more room to shrink
(until we clamp at their min-size), so it makes sense that we scale
their flex-shrink factor accordingly -- BUT -- flex items with larger
MBP do *not* have any additional ability to shrink, so it does *not*
make sense (to me at least) for the MBP to influence their scaled
flex-shrink factor.

Looking at it from a slightly different angle:
 (2) The flex-shrink scaling behavior is designed to prevent bad
scenarios where some elements might shrink to nothing, while other
elements still have plenty more room to shrink.  Yet, this bad scenario
is exactly what will happen, with the current spec text, if you've got
an item with large MBP.  That item will be "penalized" for its MBP, and
its content-box will rapidly shrink to 0 (or its min-size clamp) as the
container shrinks, while other items with similarly-sized content-boxes
& without any MBP will shrink less rapidly.

Also, FWIW: the changeset that added the word 'outer' here was really
just cleaning up 3 stale mentions of "flex basis" (replacing them with
"hypothetical main size"), and in this one instance (out of the three),
the word "outer" was added as well. This introduction represented a
behavior-change, which may not have been intended by that commit.

Changeset link: https://dvcs.w3.org/hg/csswg/rev/f4b327e99f43

(Ultimately, I'm OK with either behavior (it's easy enough to switch);
it just makes more sense to me that the MBP should be excluded from the
scaling, per (1) and (2) above.)

Thanks,
~Daniel

Browser versions tested: Firefox 36 (Nightly), Chrome 40 (dev), IE11

Received on Thursday, 23 October 2014 21:52:22 UTC