[css-flexbox-1] Intrinsic sizing algorithm seems to produce 0 for many common cases

[dholbert]

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?

[tabatkins]

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]

I think the options we have are:

• No change: flex basis is ignored for determining min-content/max-content sizes of flex containers, we only care about the min-content/max-content contributions of the item's contents.
• Treat width/height, but not flex-basis as a floor on the max-content size.
• Treat flex-basis, but not width/height, as a floor on the max-content size.
• Take max(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]

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]

Yeah, it's the max-content contribution of the items / max-content size of the container we're concerned with here.

[css-meeting-bot]

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 size

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

[fantasai]

Edits checked in! @dholbert, would please let me know if they are satisfactory. :)

[astearns]

Reopening for testcase need.