- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 28 Oct 2014 10:18:41 -0700
- To: Daniel Holbert <dholbert@mozilla.com>
- Cc: www-style <www-style@w3.org>
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