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

[emilio]

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?

[emilio]

cc @lilles @dholbert

[dholbert]

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

[Loirooriol]

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

[lilles]

Adding @davidsgrogan @cbiesinger for Blink.

[cbiesinger]

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.

[dholbert]

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.

[dholbert]

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.

[Loirooriol]

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

[camsteffen]

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

[bfgeek]

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