Closed Bug 1088165 Opened 7 years ago Closed 7 years ago

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


(Core :: Layout, defect)

Not set





(Reporter: dholbert, Unassigned)


(Blocks 1 open bug)



(1 file)

Attached file 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.

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.

  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
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.

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):

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:

(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:

As long as that change sticks, this bug is now INVALID, since our existing behavior matches the (amended) spec.
Closed: 7 years ago
Flags: needinfo?(dholbert)
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.