- From: Tab Atkins Jr. via GitHub <sysbot+gh@w3.org>
- Date: Wed, 15 Jan 2025 19:44:06 +0000
- To: public-css-archive@w3.org
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. -- GitHub Notification of comment by tabatkins Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/11480#issuecomment-2593794353 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 15 January 2025 19:44:07 UTC