Re: [csswg-drafts] [css-flexbox-2] Add flex-wrap: dense (#3071)

(Moving some comments from #11480 to the dedicated issue issue.)

The Grid 3 proposal contains a [`masonry-slack`](https://drafts.csswg.org/css-grid-3/#masonry-slack) property, which relaxes the constraints on what tracks are "the least filled", so a *small* difference in track heights doesn't force the tracks to fill in a surprising order.

#11480 proposes, as part of generalizing a few other layout properties, a new `item-slack` property with the same value space (and if accepted, replacing the `masonry-slack` property), and as part of that, proposes adding a similar "slack" behavior to Flexbox, to be controlled by this property. It also proposes an `item-pack` property that controls the "dense" behavior from Grid and Masonry, and proposes it be applied to Flexbox as well.

I had some feedback on the details of the slack and dense proposals for Flexbox, but it was requested that feedback be moved to a new issue. I'm copying the comments here, then I'll delete them from the original issue.

-------

[**Original Comment from fantasai**](*https://github.com/w3c/csswg-drafts/issues/11480#issue-2781495226) 

> Defining dense packing for Flexbox would mean that instead of breaking lines as soon as an item can’t fit, we try to cram in one more, triggering flex-shrink behavior instead of flex-grow on that line. See #3071>.
> 
> For Flexbox, slack could say at what point you switch from loose packing to cramming:
> * In normal mode, 10px slack would mean “if there’s only 10px overflow on this line when adding the next item, cram it in anyway, as squeezing in an extra 10px is no big deal”.
> * In dense mode, 10px slack would mean “if there’s only 10px empty space left on this line, don’t try to cram in the next item, that’s too much cramming”.

-----

[**Reply 1 from me**](https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2591555448)

[re: the proposal for "dense" Flexbox behavior]

> What Grid does with dense is always start its search from the top, rather than maintaining a cursor and always proceeding forward. This way, a large item that doesn't fit on one line and gets moved to the next doesn't forever leave an empty space on the preceding line. Translating this to Flexbox, I'd assume it places each item in the first flex line that still has enough space for the item's base size, rather than always putting the item in the last line. It wouldn't change the wrapping behavior or force shrinking in new cases; items would still only shrink if they were the sole item on the line and still too large. I think this would be a useful behavior, as it helps avoid the "one line gets REALLY STRETCHY items because a large item had to wrap to the next line" that today's Flexbox gives.

[re: the proposal for "slack" Flexbox behavior]

> I really like that the initial value of 0 is just today's Flexbox behavior, and higher values start enabling some slack in line-breaking. However, I don't like that in the proposal for the dense behavior, higher values make it stricter rather than looser. Given that this proposed definition of dense still only ever puts one additional item on a line, I think that *-slack is enough to define it all on its own; item-slack: infinite would give the proposed dense behavior of "always cram one extra item on the line", and smaller values make it stricter. I recognize this is a slightly different constraint -- it's checking how much the next item would overflow by, rather than checking how much space is left in the line -- but I think in practice the two constraints are reasonably interchangable. This then frees up dense to be the behavior suggested in †¹, which is closer to Grid's dense behavior.

-----

[**Reply 2 from fantasai**](https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2591708089)

> I think you're misreading the proposal. Higher values are looser adherence to dense packing in the proposal (i.e. the larger the slack, the looser packing we allow).

-----

[**Reply 3 from me**](https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2593794353)

> Ah, I'm not misreading, we're just thinking of the condition in opposite ways.
> 
> My objection is partly semantic (this is using slack as a negative condition, while the other usages are a positive condition), but the more important one is practical. The point of the slack is to give you some control over the decision of whether to keep the overflowing item on the line (causing shrinkage) or push it to the next line (causing flexing). What's more important for that decision: how much of the item does fit on the line, or how much of the item doesn't fit on the line?
> 
> As a practical example, say your flexbox is 1000px wide, and the line is currently 800px filled, so 200px left. The next item is one of two possible elements: either a 250px item, or a 2000px item (lots of text, guaranteed to shrink and internall wrap). What's more important for deciding whether to squeeze either item in or push it to the next line: the fact that there's 200px left on the line, or the fact that one item overflows by 50px (requiring shrinking from 1050 to 1000) and the other overflows by 1800px (requiring shrinking from 2800 to 1000)?
> 
> I think it's pretty clear that it's the latter. The 200px is irrelevant for the decision, all that matters is how much shrink the item is going to force everything on the line to do if you cram it in. You're probably okay with the 50px overflow (only 5% over!), but definitely not okay with the 1800px overflow (180% over!).
> 
> If you can roughly predict the size of the items, the two numbers are interchangeable: if one is X, the other is size - X, so you can author against either number just fine. But if you can't predict the item sizes, the amount of overflow is, I think, definitely what you want to author against.
> 
> So, I think this sort of "dense" behavior is better achieved by just using the proposed "normal flexbox" behavior and setting item-slack: infinite. You can use lower numbers to control how densely you pack.
> 
> This then frees up dense to instead act more similar to Grid and Masonry, where it causes the item to try and find an unfilled spot that it'll fit in. I think this would be useful any time someone has an unordered set of data in a multiline flexbox, so one large item wrapping to the next line doesn't leave a ton of free space on the preceding line. And then dense will still work with item-slack - the item finds a line that it can fit in or overflow by the slack amount or less, allowing a little bit of squish.

-------

[**Reply 4 from me**](https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2593806696)

> Ah, here's the positive-condition version of your dense proposal (I rewrote the above comment three times, and of course didn't think of this until after I hit Comment): dense forces the flexbox lines to be completely filled if possible -- aka 0 free space -- by cramming in one more item when needed. item-slack loosens that; flex lines are allowed to have up to the slack amount of free space, but no more.
> 
> That said, my practical objection still stands. If you can predict item sizes, then "amount of leftover space on the line" and "amount the item overflows by" are interchangeable and we can use either; if you can't predict item sizes, then it's still more important to control how much overflow is happening than how much free space is left. And dense can then be employed to allow some light rearranging to reduce the free space.

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


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

Received on Wednesday, 29 January 2025 01:26:49 UTC