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

> 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.

Intuitively, I'd guess that most column-wrap containers DO have a height constraint. Because otherwise, why would an author use a multiline container in the first place? Single-line seems more straightforward. I suppose someone would use multiline on an indefinite height container If they don't want the flex line to stretch to the full width of the container, but that strikes me as niche.

All that said, I'm happy to apply the multicol precedent to column-wrap flex containers. Hopefully there won't be that many overflow problems in practice.

> 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.

I suppose the competing principles are (1) we want to obey whatever authors specify (i.e. not treat percent widths as auto) but (2) we don't want the container's max-content width to result in overflow. I found it so frustrating to change properties and not see any subsequent change when I was a key-mashing web developer so I'd put (1) over (2) even though (1) results in some overflow. If the author doesn't want the overflow, they'll figure out to remove the specified percent width, which is what (2) would do for them and not give them a choice to opt out.

> 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.)

Agree. We aren't going to implement min/max-content block sizes anytime soon so I didn't consider this issue.

I don't see why we'd deviate from #1, if #1 is what we did for multicol and will do for column wrap inline sizes. Like, what is substantially different about the row-wrap container that we would do something different? If we go with #2, would whatever reasoning we use to choose #2 also apply to column-wrap flex containers discussed above? (Sorry, I know this isn't very helpful.)

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


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

Received on Tuesday, 12 April 2022 22:57:59 UTC