Use *outer* flex base size to compute scaled flex shrink factor

RESOLVED INVALID

Status

()

Core
Layout
RESOLVED INVALID
4 years ago
4 years ago

People

(Reporter: dholbert, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 8510448 [details]
testcase 1

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.
Flags: needinfo?(dholbert)
OS: Linux → All
Hardware: x86_64 → All
"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]
Blocks: 1055888
(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
Last Resolved: 4 years ago
Flags: needinfo?(dholbert)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.