Closed Bug 1162754 Opened 9 years ago Closed 2 years ago

Don't bother measuring for min-height:auto, for flex items with "flex-shrink:0; flex-basis:auto; height: [definite]" (e.g. from "flex:none;height:[definite]" shorthand)

Categories

(Core :: Layout: Flexbox, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: dholbert, Unassigned)

References

(Blocks 1 open bug)

Details

TreeHerder has a bottom panel with this styling:

  flex: 0 0 auto;
  height: 35%;

value

But we don't actually need that trial layout -- it will never actually influence our sizing, because:
 (0) The 'height' is definite (there's a valid container-height for 35% to resolve against, in this case). So it's effectively a fixed value, let's say 70px.

 (1) The flex item has "flex-shrink:0", so it's not in danger of shrinking *below* its flex base size (of 35% == e.g. 70px)

 (2) "min-height:auto" takes definite "height" values into consideration, and will lower its value as-necessary to accomodate them.

So: if the content height happens to be *smaller* than 70px, then we're in no danger of violating it (since flex-shrink is 0 and our flex base size is larger than our min-height), so it doesn't actually impact layout.

And if the content height happens to be *larger* than 70px in this example, then we'd end up picking "70px" as the final size for min-height:auto, so the content height won't actually matter.

So, there's no actual need to measure the content height.
Blocks: 1159819

Daniel, do we still need to fix this bug? I believe we still need to reflow the inflexible flex item at least once, which can be a measuring reflow. In this specific scenario, the flex item cache mechanism is likely to find the item's main size not changed, and skip its final reflow.

Type: defect → enhancement
Component: Layout → Layout: Flexbox
Flags: needinfo?(dholbert)

Yeah, this feels probably-not-worth-fixing (if I'm correctly understanding what I described in comment 0).

I think the min-height:auto measuring reflow is unnecessary (strictly speaking) in the scenario described in comment 0, but it also is unlikely to be a perf issue since we'll cache the result and shouldn't repeat that measurement on incremental reflows of the page (unless the content actually changes).

The logic to determine that it's unnecessary is probably not worth the added complexity (though we can always reopen this if we discover a scenario where it's a clear perf win).

Status: NEW → RESOLVED
Closed: 2 years ago
Flags: needinfo?(dholbert)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.