Closed Bug 1088165 Opened 5 years ago Closed 5 years ago
Use *outer* flex base size to compute scaled flex shrink factor
The flexbox ED currently defines the "scaled flex shrink factor" as follows: # 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 Note that it says *outer* flex base size. We currently use the *inner* flex base size, I think. Testcase attached, with two flex items, which have identical sizing properties except that the first one has a margin. (So, it has a larger outer flex base size, which means it should have a larger scaled flex shrink factor, which means it should shrink by a larger amount.) Firefox Nightly & Chrome 40 both give the two flex items the same size. (so, they're not considering the *outer* base size when computing the scaled flex shrink factor) IE11 shrinks the first item more, which I think is correct per spec. So: ACTUAL RESULTS: purple & orange item are the same width. EXPECTED RESULTS: purple item should be skinnier.
(This hasn't changed recently -- it looks like this has included the word "outer" ever since the earliest spec draft that I can find that has "scaled" in it, which is http://www.w3.org/TR/2012/WD-css3-flexbox-20120612/ I think I must've just missed this [& so did the Blink folks] when implementing this part.)
The spec is also inconsistent about this -- it has this language higher up, in the definition of "flex shrink factor": > The flex shrink factor is multiplied by the flex basis when distributing negative space. http://dev.w3.org/csswg/css-flexbox/#flex-shrink-factor Compared to the text in comment 0, this chunk is missing the "outer" clarifier, & it says "basis" instead of "base size". I think the discrepancy is just because this text is more high-level & hand-wavy; still, it's technically contradictory & we should probably get it fixed in the spec.
OS: Linux → All
Hardware: x86_64 → All
The code that implements this is here, FWIW: http://mxr.mozilla.org/mozilla-central/source/layout/generic/nsFlexContainerFrame.cpp?rev=366b01141df5&mark=383-383#355
"outer" was added to the spec in this cset (which replaced "flex-basis" with "hypothetical outer main size" in this definition): https://dvcs.w3.org/hg/csswg/rev/f4b327e99f43 Based on the commit message (which indicated that it was just stale-language-cleanup sort of thing), I'm not clear whether this was an intentional behavior-change or not.
I emailed www-style to clarify this point: http://lists.w3.org/Archives/Public/www-style/2014Oct/0417.html (Our current behavior -- scaling by the inner flex base size -- makes more sense to me, as laid out in that message.)
[Marking as blocking Bug 1055888 (the flexbox-spec-changes tracking-bug) per comment 4]
(In reply to Daniel Holbert [:dholbert] from comment #5) > (Our current behavior -- scaling by the inner flex base size -- makes more > sense to me, as laid out in that message.) Tab replied, saying that he & fantasai agree with me, and that he's changed the ED: http://lists.w3.org/Archives/Public/www-style/2014Oct/0495.html As long as that change sticks, this bug is now INVALID, since our existing behavior matches the (amended) spec.
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.