[css-flexbox] When omitted from the flex shorthand the flex-basis value is...

@fantasai

Per spec it should be 0, but it used to be 0% and it was never changed in browsers, see https://drafts.csswg.org/css-flexbox/#change-201505-substantive:

Is there value in making this change? What compat issues can it cause other than serialization @fantasai?

Do other browsers want to make the change? Otherwise that change should maybe be reverted?

@lilles

cc @lilles @dholbert

@Loirooriol

For what it's worth, the still-open mozilla bug ~~on switching from 0 to 0%~~ is https://bugzilla.mozilla.org/show_bug.cgi?id=1368592.

This change would have a pretty big risk of causing compat issues, since it'd change the flex basis from definite to potentially-indefinite (depending on whether the flex container's main size is definite or indefinite); and that changes the decision-tree for the calculation of the flex base size in https://drafts.csswg.org/css-flexbox-1/#algo-main-item

[EDIT: as @Loirooriol noted, I had things backwards here - the current implemented behavior is 0%, whereas the spec was changed to require 0. The webcompat risk remains, though.]

@dholbert

@dholbert Isn't it the other way round? If the spec changes from 0 to 0%, since browsers are already using 0%, there won't be compat issues. If browsers change from 0% to 0 to match the spec, then the flex basis will change from potentially-indefinite to definite.

@davidsgrogan

Adding @davidsgrogan @cbiesinger for Blink.

Changing 0% to 0 in browsers requires implementing the intrinsic size algorithm from the spec, especially for the block axis. Otherwise, column flexboxes with auto height would size to zero in the simple case.

@dholbert

@dholbert Isn't it the other way round?

Sorry, you're right - I had the situation backwards. But yes, browsers currently disagree with the spec, and if we changed browser-behavior (to match the spec) then it seems like it'd risk compat issues, due to taking a different path through the decision tree at https://drafts.csswg.org/css-flexbox-1/#algo-main-item. That's the gist of what I meant to say above.

Here's a concrete example of where a browser implementing the spec might present a webcompat issue:
https://bug1368592.bmoattachments.org/attachment.cgi?id=9329106

<style>
  .c {
    display: inline-flex;
    flex-direction: column;
    width: 100px;
    min-height: 100px;
    /* important: height is unspecified, which gives special significance
       to 0% height values on our children (e.g. implicit flex-basis:0%) */
    border: 1px solid black;
  }
  .c > * {
    min-height: 5px;
    background: orange;
  }
  .flex0 { flex: 0; }
  .flex0_0 { flex: 0 0; /* note: 2nd unitless-0 just parses as flex-shrink */ }
  .flex0_0pct { flex: 0 0%; }
  .flex0_0px { flex: 0 0px; }
  .flex0_0_0 { flex: 0 0 0; }
</style>
<div class="c"><div class="flex0">flex:0</div></div>
<div class="c"><div class="flex0_0">flex:0 0</div></div>
<div class="c"><div class="flex0_0pct">flex:0 0%</div></div>
<div class="c"><div class="flex0_0px">flex:0 0px</div></div>
<div class="c"><div class="flex0_0_0">flex:0 0 0</div></div>

Here's a screenshot showing how that testcase renders in current WebKit / Blink / Gecko:

In the first two boxes in the testcase, the orange background (the flex item) renders as tall as its text, by virtue of the fact that browsers are interpreting the flex expression as implying flex-basis:0%, and browsers are then resolving the 0% to content due to the indefinite size of the flex container.

If we implement the spec change and use unitless 0 (i.e. 0px) instead, then browsers would render the first two boxes the same way that they render the last two boxes, with a collapsed flex item height. This may cause webcompat issues, particularly in cases where the flex item has overflow:hidden|scroll|auto and collapses away without overflow being visible.

More concerning scenario, from a webcompat perspective:
https://bug1368592.bmoattachments.org/attachment.cgi?id=9329111

This is the same as my previous testcase, but with overflow:auto instead of min-height:5px (possibly more representative of real-world content; note that any non-default value of overflow would make the same point here).

In this testcase, items with implicit flex-basis:0% still render just fine, but items with flex-basis:0 or 0px don't render at all:

If browsers were to implement the spec change, then the first two black-bordered boxes here would become blank (like the last two). I'm a bit worried that real-world web content would end up with pieces unexpectedly disappearing for that reason.

Maybe a counter could be added, or a HTTPArchive search or something, to see how many websites would be impacted?

LibWeb: Fix broken handling of `flex: <flex-grow>` shorthand

Is there value in making this change?

I would like to cast a vote for "yes". I've tripped over this a lot because 0% height can get translated to "auto". The fact that 0 and 0% are different is highly confusing. A unitless default would be better for the principle of least surprise.

Example sandbox

Fwiw - this likely isn't web compatible anymore. Spec should be changed back to reflect reality.

Note to future self - this definitely wont be web compatible anymore.

I might not make the call tomorrow - but specifically the case below is relatively common + lots of variations on this:

<!DOCTYPE html>
<div style="width: 100px; display: inline-flex; flex-direction: column; border: solid 2px;">
  <div style="flex: 1; overflow-y: scroll;">content</div>
</div>

<div style="width: 100px; display: inline-flex; flex-direction: column; border: solid 2px;">
  <div style="flex: 1 1 0px; overflow-y: scroll;">content</div>
</div>

(I'm happy to take this topic is Ian's not in.)

The CSS Working Group just discussed [css-flexbox] When omitted from the flex shorthand the flex-basis value is..., and agreed to the following:

RESOLVED: Switch omitted flex-basis back to 0% for compat, add a note to the spec about it

The full IRC log of that discussion

<fantasai> TabAtkins: Along while ago, we defined that the value of flex-basis when you don't specify the basis would be 0%
<fantasai> TabAtkins: This was specifically to trigger indeterminate behavior
<fantasai> TabAtkins: Later tried to change it, to say that you get 0px
<fantasai> TabAtkins: We were unclear at the time whether it would be Web-compatible to do
<fantasai> TabAtkins: Implementations have not really followed the spec change here. They've kept 0%
<fantasai> TabAtkins: At this point, we're fairly certain it can't be changed
<fantasai> TabAtkins: So that it doesn't go down to zero
<fantasai> TabAtkins: We see cases where they are depending on that.
<fantasai> TabAtkins: So proposal is to revert
<fantasai> TabAtkins: Probably need to call out in the spec that it's a little weird but required for back-compat
<TabAtkins> fantasai: I think at this point this is probably correct
<TabAtkins> fantasai: the original idea is we would rely on automatic minimum to prevent these problems we were trying to solve with 0%, that gives a little more flexilibity
<TabAtkins> fantasai: but that does give slightly different behavior, basis of max-content vs flooring it at min-content is quite different, or at least can be different
<fantasai> PROPOSED: Switch back to 0% for compat, add a note to the spec about it
<fantasai> RESOLVED: Switch omitted flex-basis back to 0% for compat, add a note to the spec about it

Navigation Menu

Repository navigation

[css-flexbox] When omitted from the flex shorthand the flex-basis value is... #5742

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[css-flexbox] When omitted from the flex shorthand the flex-basis value is... #5742

Description

Activity

emilio commented on Nov 24, 2020

dholbert commented on Nov 25, 2020

Loirooriol commented on Nov 25, 2020

lilles commented on Nov 25, 2020

cbiesinger commented on Nov 25, 2020

dholbert commented on Nov 26, 2020

dholbert commented on Apr 18, 2023

dholbert commented on Apr 18, 2023

Loirooriol commented on Apr 18, 2023

camsteffen commented on Aug 19, 2024

bfgeek commented on Aug 27, 2024

bfgeek commented on Jul 27, 2026

bfgeek commented on Jul 29, 2026

tabatkins commented on Jul 29, 2026

css-meeting-bot commented on Jul 29, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions