I'm reviewing @cbiesinger 's testcase for the (not-implemented-anywhere AFAIK) flexbox intrinsic sizing algorithm, over in web-platform-tests/wpt#5791 , and I think we might've uncovered some unintended spec behavior with the intrinsic sizing algorithm. (And maybe it's intended? But it doesn't match biesi's testcase's expectations, so I want to be sure.)

In particular: it seems to me that in many common cases (with empty flex items at least), the algorithm requires that flex items contribute 0 to their container's intrinsic size, and the container will end up with an intrinsic size of 0 as a result.

For example, consider these two cases:

  <div style="display:inline-flex;">
    <div style="flex: 1 1 200px"></div>
  </div>

  <div style="display:inline-flex">
    <div style="flex: 1 1 auto; width: 200px"></div>
  </div>

Here, you might reasonably expect that each flex item & flex container to be 200px wide. But in both cases, the algorithm ends up sizing the item & container to 0px. This is because:

• the items' contributions depend on their max-content main size which is zero in both cases since they don't have any contents (and an element's min/max-content size isn't influenced by its flex-basis or width).
• The spec says the items' flex-basis doesn't get to clamp their contributions because the items are both growable and shrinkable.

This behavior (ending up 0-sized) kind of makes sense, because the items have no content and no min-width/max-width properties, which mean's they're "OK" being 0-sized, in a sense -- there's no overflow. Still: it seems odd for an element with width:200px to end up being 0-sized, in a scenario with no constraints.

@tabatkins @fantasai , am I reading the spec correctly here? And is this zero-sizing the intended spec behavior for cases like this?