- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 18:22:37 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox-1] Clamp "hypothetical main size" to be non-negative?`, and agreed to the following: * `RESOLVED: flooring of the hypothetical main size is limited to balanced wrapping flexboxes, and we're only using it for line breaking purposes.` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: currently in flexbox, when we do line breaking we use the hypothetical main size<br> <kbabbitt> ... outer size, including effective margins and negative margins<br> <kbabbitt> ... can shrink box all the way to negative sizes if needed<br> <kbabbitt> ... this is widely implemented, can hjave a negative size flex item that removes items from line<br> <kbabbitt> ... complicates balance, there's an efficient algo for correctly balancing if everything is clamped to 0+ size<br> <kbabbitt> ... n^2 if not clamped<br> <kbabbitt> ... 2 possibilities here<br> <kbabbitt> ... could just for line breaking during a balanced flexbox, clamp outer main sizes to 0<br> <kbabbitt> ... could also go further and say at all times in flexbox, outer main sizes are clamped to 0<br> <kbabbitt> ... so a normal wrapping flexbox also line breaks based on minimum of 0 size<br> <kbabbitt> ... and possibly go even further and say that's 0 for all layout purposes<br> <kbabbitt> ... lays out as 0 size when putting things on line<br> <kbabbitt> ... that was oriol's preference<br> <oriol> q+<br> <kbabbitt> ... I'm okay with any of these three possibilities, limit to balance line break, limit to all line break, or all flex things<br> <kbabbitt> ... since there's a preference from oriol I suggest we go with that, clamp to 0 for layout purposes<br> <kbabbitt> ... this is a potentially observable behavior change<br> <kbabbitt> ... iank_'s intuition is that this should be okay?<br> <kbabbitt> iank_: yeah I think so, a little more worried about oriol's proposal, can try it and see<br> <kbabbitt> ... from a perspective of, wrapping flexboxes are far more rare than non-wrapping<br> <kbabbitt> ... just affecting line break would not touch non-wrapping<br> <kbabbitt> ... because ... oriol your proposal would mean that, if you've got margins which are -100px<br> <kbabbitt> ... that item's auto box size would be ?, couldn't go below 100p[x<br> <dholbert> s/auto/border/<br> <kbabbitt> oriol: to add more context, we already resolved this in last f2f<br> <Rossen> ack oriol<br> <kbabbitt> ... didn't like the inconsistency of only treating as not-negative for line breaking but not layout<br> <kbabbitt> ... this has the potential of adding empty space on lines<br> <kbabbitt> ... common complaint that authors don't know where empty spaces are coming from<br> <kbabbitt> ... think empty spaces are bad when not doing line balancing<br> <dholbert> q+<br> <kbabbitt> ... fine with previous resolution saying that when doing line balancing it's already the point that you're doing it already<br> <kbabbitt> ... fine with restricting to line balancing cases<br> <kbabbitt> ... other option I was proposing was to do it in both line breaking and layout<br> <kbabbitt> ... maybe it's true int he issue I was saying this is what we should do, but after that preference is previous option to restrict to line balancing<br> <kbabbitt> ... potential of being less compatible<br> <kbabbitt> ... but at least it provides some behavior that is self consistent so also good for me<br> <kbabbitt> ... I posted an example in the issue wher eyou can see you get some empty space with previous resolution<br> <kbabbitt> ... if we do this behavior of clamping to nonnegative in line breaking and layout, it's a different behavior from what browsers are doing but no empty spaces so more consistent<br> <kbabbitt> ... my position has shifted to previous resolution on line balancing<br> <kbabbitt> TabAtkins: so previous example with line layout partiall emptuy, you're okay with this?<br> <kbabbitt> oriol: this example is not using line balancing<br> <Rossen> ack dholbert<br> <kbabbitt> dholbert: a little skeptical of the concern about empty space at end of line<br> <kbabbitt> ... if any item is flexible they'll just grow to absorb emptyu space<br> <kbabbitt> ... if they aren't you'll have emptuy space at end of line anyway<br> <kbabbitt> ... picture from oriol is a case where items could exactly fill the line but got pushed to next line<br> <kbabbitt> ... that specific case I agree is a little weird but think its a little bit of an edge case<br> <kbabbitt> ... like iank_ was starting to say, concerned about changing behavior for regular layout<br> <kbabbitt> ... intuition is people use negaqtive margins to move flex items around<br> <kbabbitt> ... worried it would be a breaking change to floor to 0 for flex items in general<br> <kbabbitt> ... think it makes sense to do for line wrapping regardless of balancing<br> <Rossen> ack fantasai<br> <Zakim> fantasai, you wanted to ask about gaps (but after Oriol comments)<br> <kbabbitt> fantasai: agree with iank_ that we should not change behavior in ? flexbox<br> <kbabbitt> ... think we're likely to have compat issues if we do that<br> <astearns> s/?/single-line/<br> <kbabbitt> ... also lean twoards not changing fro non-balancing flexboxes for compat reasons<br> <iank_> (the flooring affects flexing in particular for deciding the final flexed size)<br> <kbabbitt> ... flexbox has been in the wild long enough that there's a reasonable likelihood authors are using negative margins to position items on top of each other, concerned about changing behavior<br> <kbabbitt> ... it's a little risky and would be better not to change it<br> <kbabbitt> ... for balancing we should do some kind of flooring<br> <kbabbitt> ... question I had there is what about gaps<br> <kbabbitt> ... is it the outer size plus the gap?<br> <kbabbitt> iank_: just the outer size ignoring gap<br> <kbabbitt> ... there's reasons to do it that way<br> <kbabbitt> ... makes the calculations easier<br> <kbabbitt> fantasai: in that case I think limiting it to balancing is probably the best way to go<br> <kbabbitt> Rossen: can try to resolve on this<br> <kbabbitt> Rossen: iank_ is that good with you?<br> <kbabbitt> iank_: yes<br> <kbabbitt> fantasai: flooring of the hypothetical main size is limited to balanced wrapping flexboxes<br> <kbabbitt> TabAtkins: and we're only using it for line breaking purposes<br> <kbabbitt> fantasai: that's the second resolution<br> <kbabbitt> Rossen: any objections to either of those two?<br> <kbabbitt> RESOLVED: flooring of the hypothetical main size is limited to balanced wrapping flexboxes, and we're only using it for line breaking purposes.<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/12222#issuecomment-4172091755 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Wednesday, 1 April 2026 18:22:38 UTC