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

On Thu, Oct 23, 2014 at 2:51 PM, Daniel Holbert <dholbert@mozilla.com> wrote:
> 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

After some discussion, fantasai and I agree with you.  I've changed it
to say "inner".

~TJ

Received on Tuesday, 28 October 2014 17:19:45 UTC