Repository navigation
[css-flexbox-1] Intrinsic sizing algorithm seems to produce 0 for many common cases #1435
Description
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-basisorwidth). - The spec says the items'
flex-basisdoesn'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?
Activity
tabatkins commentedon Jun 22, 2017
It wasn't explicitly intended, no. But I'm also not sure it's something we actually want to change. ^_^ @fantasai and I will have to think on this.
fantasai commentedon Aug 8, 2017
I think the options we have are:
width/height, but notflex-basisas a floor on the max-content size.flex-basis, but notwidth/height, as a floor on the max-content size.flex-basis,width/height) as a floor on the max-content size.I'm not actually sure what's the best idea here.
@rachelandrew @jensimmons ?
dbaron commentedon Aug 23, 2017
Should these be constraining the max-content contribution (to the parent) rather than the max-content size? Otherwise I think it breaks the
max-content(etc.) values.fantasai commentedon Aug 23, 2017
Yeah, it's the max-content contribution of the items / max-content size of the container we're concerned with here.
css-meeting-bot commentedon Aug 23, 2017
The CSS Working Group just discussed
Intrinsic sizing algorithm seems to produce 0 for many common cases, and agreed to the following resolutions:RESOLVED: Change the spec to treat width and height as input for the max content sizeThe full IRC log of that discussion
<dael> Topic: Intrinsic sizing algorithm seems to produce 0 for many common cases<dael> Github topic: https://github.com//issues/1435
<fantasai> Options: https://github.com//issues/1435#issuecomment-321098718
<dael> fantasai: There is an issue filed by dholbert pointing out max-content of a flex container is only defined by max content size of its content and flex-basis isn't taken into account. Empty elements in flex with a basis it shrinks to 0.
<dael> fantasai: dholbert pointed out this is unintuitive. We did give it a size
<dael> fantasai: We have options here. No one has a good arguement for one over another. We need WG or community opinion. We could do nothing and leave as-is. We could treat specified width or height as a size that needs honor and ignore flex-basis. WE could do flex-basis and ignore width and height. And this would all be inflated by max-content.
<dael> fantasai: If I was going to pick randomly I would say use width and height but not flex-basis
<dael> Bert: Sounds like it's not a serious problem, but I may be misreading. Any opinions?
<dael> gregwhitworth: I'd agree with width and height but not flex-basis. My only worry is, I don't expect people to hit this on web but they prob wouldn't know they have empty flex.
<dael> gregwhitworth: Any compat issues?
<dael> rachelandrew: As an author it's not an issue I"ve seen.
<dael> rachelandrew: I'd prob agree width/height not flex-basis makes sense.
<dael> Bert: That's one in support. Other opinions?
<dael> Bert: Other options...flex-basis as well as width/height and take the max, they are less desireable. Did ne not want to discuss those?
<dael> fantasai: flex-basis is a start place for flexing, it's an input. Width and height are set. In that case you're setting something explicit and everywhere else in CSS we take that.
<dael> Bert: Anybody want to argue in favor of flex-basis or max of that and width?
<dael> Bert: Maybe we drop those.
<dael> Bert: So only no change or look at width/height
<myles> present+: myles
<dael> Florian: Sounds like a good change, but is anyone rushing to impl?
<dael> fantasai: I'm not sure but dholbert is planning to look at flex box.
<dael> gregwhitworth: Looking at the test cae we have interop. It's a worthwhile change, we should make it.
<dael> Bert: Okay, they we need buy in from more impl.
<dael> Florian: We have 2 at least. That's a good start.
<dael> Bert: Is TabAtkins on?
<dael> fantasai: He's just IRC.
<bradk> Is there existing content that depends on current interop behavior?
<dael> Bert: I'm hearing some support for looking at width/height but not flex-basis which is a change in spec.
<dael> fantasai: Yes.
<dael> Bert: Do we put that up? Change the spec to treat width and height as input for the max content size
<dael> Bert: Who is in favor, who is against?
<dael> Florian: In favor
<rachelandrew> +1
<dael> Bert: I only hear in favor.
<dael> RESOLVED: Change the spec to treat width and height as input for the max content size
<dael> Bert: fantasai will you write text? or TabAtkins ?
<dael> Bert: Whose action?
<TabAtkins> We'll take care of it, don't worry
<dael> fantasai: We'll do it, don't worry.
<dbaron> I guess I'm surprised they weren't already an input to the max-content contribution, given that they're an input for other layout modes.
<TabAtkins> As long as it shows up in the issue
fantasai commentedon Sep 6, 2017
Edits checked in! @dholbert, would please let me know if they are satisfactory. :)
[css-flexbox] Clarify specified size in previous edit. #1435.
astearns commentedon Sep 27, 2017
Reopening for testcase need.