- From: Daniel Holbert <dholbert@mozilla.com>
- Date: Thu, 23 Oct 2014 14:51:55 -0700
- To: www-style <www-style@w3.org>
- CC: "Tab Atkins Jr." <jackalmage@gmail.com>
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