Re: [csswg-drafts] [css-flexbox] column wrap intrinsic size algorithm can make inline min-content > max-content (#6777)

So the goal of the min-content and max-content sizes are to represent the smallest and largest sizes that the box and its contents could lay out into without triggering overflow or leaving excess space. And the intention is that the box, when set at that size, would lay out accordingly, with its contents in its fully compressed or fully unwound state, fitting its container exactly.

But for column wrap flex items, it doesn't quite work that way. If we figured out the right size for a min-content layout, for example, we'd size the flex container at that size... and then tell its items to lay out into their container. Which means they'd lay out against the available space we calculated for all the flex lines combined, rather than the min-content size of their own flex line. There's basically no good answer here.

I think the best (least nonsensical) thing we can do for the min-content size is to treat it as a single-column flex container, and just take the largest min-content contribution among the items. Which will result in overflow if the flex container has a height constraint, but at least there's some relationship between this size and fitting the contents.

For the max-content size, if we lay out each item at its max-content size, fill the columns, and then wrap a box around that, we can get a size that fits its contents exactly most of the time. The exception would be if we have percentage-sized items: they'll try to resolve against the width calculated for all the flex lines combined, and be too big. Maybe we can avoid that by suppressing percentage resolution (treating as `auto`) in these cases, i.e. when the percentage is cyclic, like we do for percentage heights in block layout.

Note that this is essentially just a direct translation of what we earlier determined was the desired behavior for multicol under these situations: <https://github.com/w3c/csswg-drafts/blob/main/css-sizing-4/intrinsic-sizing-notes.bs#L124> - under a min-content constraint without a set number of columns, assume it's just one column; under a max-content constraint with restrained height, "just do layout" and return the result.

Next interesting question is what about `row wrap` flex containers. Do we need to do something special here as well?

Consider this case:
```
item { 
    grid-template-rows: minmax(10px, 100px);
}

<outer height="min-content">
  <flex container row wrap width="tiny">
    <item/>
    <item/>
  </flex>
</outer>
```

I think the two options we have here are:
* Do the same as for `column wrap` containers: take the min-content size as if it were a single row; or
* Always size wrappable flex lines under a max-content constraint, never passing in a cyclic height or a min-content constraint from their container.

The tricky part here is going to knowing when to break cyclic sizing.

Neither option is *great*, but they at least get a size that relates to the layout, rather than a size that's effectively random, being derived from a layout that we no longer have. (#1 gives you a 10px-tall flexbox, overflowing due to having two 10px-tall items; #2 gives you a 200px tall flexbox containing two 100px-tall items. The current spec gives you a 20px-tall flexbox, overflowing due to having two 20px-tall items, which is effectively random as far as the author is concerned.)

Thoughts?


-- 
GitHub Notification of comment by fantasai
Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/6777#issuecomment-1071211730 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Thursday, 17 March 2022 18:52:55 UTC