Closed
Bug 1088165
Opened 10 years ago
Closed 10 years ago
Use *outer* flex base size to compute scaled flex shrink factor
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
INVALID
People
(Reporter: dholbert, Unassigned)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
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.
Reporter | ||
Comment 1•10 years ago
|
||
(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.)
Reporter | ||
Comment 2•10 years ago
|
||
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.
Reporter | ||
Updated•10 years ago
|
Flags: needinfo?(dholbert)
OS: Linux → All
Hardware: x86_64 → All
Reporter | ||
Comment 3•10 years ago
|
||
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
Reporter | ||
Comment 4•10 years ago
|
||
"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.
Reporter | ||
Comment 5•10 years ago
|
||
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.)
Reporter | ||
Comment 6•10 years ago
|
||
[Marking as blocking Bug 1055888 (the flexbox-spec-changes tracking-bug) per comment 4]
Blocks: flexbox-spec-changes
Reporter | ||
Comment 7•10 years ago
|
||
(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: 10 years ago
Flags: needinfo?(dholbert)
Resolution: --- → INVALID
You need to log in
before you can comment on or make changes to this bug.
Description
•