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:
flex-basis or width).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?
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.3