[css-flexbox-1] Intrinsic sizing algorithm seems to produce 0 for many common cases #1435
Comments
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. |
I think the options we have are:
I'm not actually sure what's the best idea here. |
Should these be constraining the max-content contribution (to the parent) rather than the max-content size? Otherwise I think it breaks the |
Yeah, it's the max-content contribution of the items / max-content size of the container we're concerned with 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 <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 |
Edits checked in! @dholbert, would please let me know if they are satisfactory. :) |
Reopening for testcase need. |
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:
flex-basis
orwidth
).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 withwidth: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?
The text was updated successfully, but these errors were encountered: