Join GitHub today
[css-flexbox-1] Intrinsic sizing algorithm seems to produce 0 for many common cases #1435
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:
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:
This behavior (ending up 0-sized) kind of makes sense, because the items have no content and no
referenced this issue
May 21, 2017
I think the options we have are:
I'm not actually sure what's the best idea here.
The CSS Working Group just discussed
The 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
<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