- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Wed, 01 Apr 2026 18:09:35 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox] Flex lines count`, and agreed to the following: * `RESOLVED: no-wrap should never wrap. line count is ignored for no-wrap flexboxes.` * `RESOLVED: flex lines continue to shrink around their contents. balance is the same as wrap in terms of line sizing.` * `RESOLVED: Percentages resolve against the container size, but available space is divided by the line count` * `RESOLVED: used line count is capped by the number of items` * `RESOLVED: flex-wrap: nowrap | [ wrap | wrap-reverse] || balance` * `RESOLVED: flex-line-count: <integer>, will work on rest later` <details><summary>The full IRC log of that discussion</summary> <kbabbitt> TabAtkins: we resolved a little while ago to add flex-wrap-balance<br> <kbabbitt> ... we did not resolve on exactly how to ensure you balance across a minimum number of lines<br> <kbabbitt> ... if you know your layout will want 2 columns or rows, for examp[le<br> <kbabbitt> ... wikipedia's reference section on bottom of page is usually 2 columns wide<br> <kbabbitt> ... if you want to use flex-wrap-balance, without a minimum lines control, you have to use a max-height that will give 2 lines worth of stuff<br> <kbabbitt> ... you end up with overflow not great<br> <kbabbitt> ... better to just say I have 2 columns<br> <kbabbitt> ... had a little discussion about waht that syntax would be<br> <kbabbitt> ... after discussing with iank_ our proposal is<br> <kbabbitt> ... flex-line-count: <integer><br> <kbabbitt> ... which provides minimum number of lines it will balance across<br> <kbabbitt> ... can result in more lnes than specified if you have enough items to fill up your main axis<br> <kbabbitt> ... but in wikipedia case I mentioned where References section doesn't have a height, it wont' ever overflow<br> <kbabbitt> ... fantasai in earlier discussion brought up functinoality like multicol<br> <kbabbitt> ... where instead of giving number of lines, you give size of line<br> <kbabbitt> ... very reasonable, there's a few ways we could have done that<br> <kbabbitt> ... could have adopted multicol approach with flex-line-size and have them fight like in multicol<br> <kbabbitt> ... proposal instead is to create a new function only usable in flex-line-count and column-count<br> <TabAtkins> auto-fill( <length-percentage> )<br> <kbabbitt> ... a special purpose function that take a length-percentage and resolves to integer number of times you can repeat that into space taking gaps into account<br> <kbabbitt> ... column-width logic<br> <kbabbitt> ... benefit of doing it this way instead of copying multicol is that because it's an integer it can be used in math functions e.g. clamp()<br> <kbabbitt> ... can guarantee a min and max number of columns to resolve to<br> <kbabbitt> ... not currently possible in multicol<br> <kbabbitt> ... e.g. at least 2 columns 100px wide<br> <astearns> auto-fill() seems like it could be used in more places…<br> <kbabbitt> ... would allow that in multicol<br> <kbabbitt> ... could min-max it<br> <kbabbitt> ... get column count number determined appropriately<br> <kbabbitt> ... some layout details about line size<br> <kbabbitt> ... open questions:<br> <kbabbitt> ... how do lines size? flexbox have 2 modes<br> <kbabbitt> ... nowrap, line fills available space<br> <kbabbitt> ... wrap, wraps the elements regardless of how large flexbox is<br> <kbabbitt> ... have to decide between these two<br> <kbabbitt> ... proposal is, since balance is close to wrapping flexbox, we adopt wrapping behaviort<br> <kbabbitt> ... balanced flexbox's lines are sized according to contents<br> <kbabbitt> ... only change is, while laying out lines, if we have a line count, we adjust available space accordingly<br> <kbabbitt> .<br> <kbabbitt> .. if you say you want 2 columns, text will flow into half of the space and wrap appropriatelu<br> <kbabbitt> ... if you have a large element due to unbreakable word, or a whole bunch of small eleemnts, line wll shink or expand to fit<br> <kbabbitt> ... in common case, esp vertical flexboxes, will match natural size that flexbox dictates<br> <kbabbitt> ... second question, what if you don't have enough items?<br> <kbabbitt> ... 3 column sbut only 2 flex items<br> <kbabbitt> ... what do we do with 3rd line?<br> <kbabbitt> ... could preserve or collapse away<br> <kbabbitt> ... arguments both from impl and usability<br> <kbabbitt> ... usability: while I think there are arguments for keeping lines around, looking at use cases in the wild, if you only have 1 or 2 refs on wikipedia page, it does not use 2 columns<br> <kbabbitt> ... it switches to 1 column and fills entire space<br> <kbabbitt> ... suggests that when there's a tiny amount of space, people would prefer to fill space available rather than leave empty space behind<br> <kbabbitt> ... proposal for initial value is that if a line does not get filled it is discarded<br> <kbabbitt> ... does change sizing behavior<br> <kbabbitt> ... if you ask for 3 lines but have 2 items, they go in 2 50% sized lines<br> <kbabbitt> ... third question, how does no-wrap react to flex line count > 1?<br> <kbabbitt> ... could ignore it, that's the simplest<br> <kbabbitt> ... or could somewhat ignore no-wrap and preserve part of it<br> <kbabbitt> ... still however many lines you asked for but container acts similar to no-wrap<br> <kbabbitt> ... no line will overflow except the last<br> <kbabbitt> ... line sizing is more like no-wrap lines where they don't care about contents<br> <kbabbitt> ... 3 lines in no-wrap will be 1/3 of available space<br> <kbabbitt> ... similar to no-wrap single line<br> <kbabbitt> ... fourth question, wrap flexboxes have a wrap-reverse keyword<br> <kbabbitt> ... balance needs the same<br> <kbabbitt> ... might want to stack lines oppositely<br> <kbabbitt> ... suggestion is to address this with balance-reverse keyword<br> <kbabbitt> ... if no-wrap honors line counts, also need no-wrap-reverse for when no-wrap wraps<br> <oriol> q+<br> <kbabbitt> fantasai: that was a lot of information and a lot of open questions<br> <kbabbitt> ... first thing is, on question of how should sizing behavior be, like no-wrap or wrapping?<br> <kbabbitt> ... should go with, it's a wrapping flexbox and should size itself like one<br> <Rossen> ack fantasai<br> <kbabbitt> ... not sure if we want to split this up and take separate resolutions?<br> <kbabbitt> oriol: no-wrap and line count, think we should honor the no-wrap<br> <kbabbitt> ... and avoid things like no-wrap-reverse<br> <kbabbitt> fantasai: agree if we said no-wrap we shouldn't be wrapping<br> <kbabbitt> TabAtkins: one argument for no-wrap behavior. say you have a bunch of flexbox elements on page<br> <kbabbitt> ... variable amounts of items in them, want each to have 3 balanceed lines<br> <kbabbitt> ... if some don't have enough items to fill lines, we will drop lines and that container will have only 2 lines worth<br> <kbabbitt> ... if you want a consistent layout<br> <kbabbitt> fantasai: we need a switch, it shouldn't be no-wrap<br> <dholbert> +1<br> <kbabbitt> TabAtkins: okay with that switch, no-wrap was convenient to use, but I'm fine with deferring that<br> <sgill> q+<br> <kbabbitt> fantasai: seems like we all agree no-wrap should never wrap so maybe we can resolve on that?<br> <kbabbitt> TabAtkins: fine with that<br> <kbabbitt> fantasai: proposed is that no-wrap should not wrap<br> <kbabbitt> TabAtkins: line count is ignored for no-wrap flexboxes<br> <oriol> q-<br> <kbabbitt> Rossen: objections?<br> <kbabbitt> RESOLVED: no-wrap should never wrap. line count is ignored for no-wrap flexboxes.<br> <kbabbitt> fantasai: second question, how are the lines sized, should they size like no-wrap or wrapping flexbox?<br> <kbabbitt> ... think we should be consistent and size like wrapping flexbox<br> <kbabbitt> Rossen: other opinions?<br> <kbabbitt> ... or objections?<br> <kbabbitt> iank_: fantasai are you proposing we don't alter space given to items?<br> <kbabbitt> fantasai: haven't said anything about that yet<br> <kbabbitt> RESOLVED: flex lines continue to shrink around their contents. balance is the same as wrap in terms of line sizing.<br> <Rossen> ack sgill<br> <kbabbitt> sgill: was going to touch on what iank_ was going to mention<br> <kbabbitt> ... when you specify a line count, that is going to change the available space for the flex item when you're determining cross size right?<br> <kbabbitt> ... changes how we compute cross size<br> <kbabbitt> ... percentages resolve differentlyu<br> <kbabbitt> iank_: not percentages ,there's an open question there<br> <kbabbitt> ... just the available size, thinks like stretch and when calculating shrink-to-fit space<br> <kbabbitt> ... basically if you take the wikipedia example which has text content<br> <kbabbitt> ... and say flex-lines 2 if you don't have this logic the items will stretch across container width and then overflow<br> <kbabbitt> sgill: does this mean flex items will always have a definite available space in that dimension?<br> <kbabbitt> iank_: no<br> <kbabbitt> TabAtkins: if space is currently definite, we'll divide by 3, if indefinite will continue to be<br> <kbabbitt> fantasai: iank_ do you want to continue discussion on available space and resolve on that?<br> <kbabbitt> iank_: yes if there are no more questions<br> <kbabbitt> TabAtkins: this is the part of the proposal, if you request 3 lines, we divide available space by 3 modulo gaps<br> <kbabbitt> fantasai: what do we resolve percentages against, divided or original available space?<br> <kbabbitt> TabAtkins: don't care either way, iank_ wants to leave them as they are, I can see arguments either direction<br> <kbabbitt> ... given we have calc-size() you can achieve either thing<br> <kbabbitt> Rossen: what are they going to resolve against?<br> <kbabbitt> TabAtkins: percentages rely on full available space, auto-fill uses divided space<br> <kbabbitt> iank_: for the use case where you want content to overflow<br> <kbabbitt> ... definitely want my min size to be 100% for examplke<br> <kbabbitt> ... will still balance but will overflow in inline direction<br> <kbabbitt> ... satisfies that use case<br> <kbabbitt> ... without that you have to set width to 200% to achieve that behavior<br> <kbabbitt> ... little more flexible for that use case<br> <kbabbitt> fantasai: think that makes sense from use case perspective, bit weird when these things resolve against different size<br> <kbabbitt> ... don't want to think about how we implement in webkit but makes sense why you'd want it<br> <kbabbitt> Rossen: we can then resolve on percents resolving against available space<br> <kbabbitt> iank_: percentages resolve against the container size<br> <kbabbitt> ... and the available space is divided by the line count<br> <kbabbitt> ... we also have, if yuou have 2 items 3 flex lines divide by ?<br> <kbabbitt> Rossen: that's a follow up<br> <kbabbitt> ... objections<br> <fantasai> PROPOSED: Percentages resolve against the container size, but available space is divided by the line count<br> <kbabbitt> kbabbitt: available space divided by line count minus gaps?<br> <kbabbitt> iank_: yes<br> <fantasai> RESOLVED: Percentages resolve against the container size, but available space is divided by the line count<br> <kbabbitt> TabAtkins: proposed behavior, not enough behavior to fill lines, collapse away empty ones<br> <kbabbitt> ... use effective line count in previous discussion<br> <kbabbitt> ... 3 items 2 lines, use half the space<br> <kbabbitt> fantasai: line count is clamped by number of items?<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> fantasai: what about 3 items, one 100px tall others 20px tall?<br> <kbabbitt> ... will only fill 2 lines<br> <kbabbitt> TabAtkins: iank_ doesn't every line take an item first?<br> <kbabbitt> iank_: yes every liine will have one item<br> <kbabbitt> TabAtkins: because that's less unbalanced, 100/20/20 vs 100/40/0<br> <kbabbitt> fantasai: ok, given that, proposal for this one is: used line count is clamped by number of items<br> <kbabbitt> TabAtkins: yes<br> <kbabbitt> kbabbitt: clamped on lower end?<br> <kbabbitt> fantasai: yes, used line count is capped by the number of items<br> <kbabbitt> dholbert: [missed]<br> <kbabbitt> fantasai: dholbert was asking, what if break-before was used to keep items together<br> <kbabbitt> ... but we don't apply that now<br> <kbabbitt> ... if at some point that becomes a thing we'll have to rethink<br> <kbabbitt> Rossen: objections?<br> <kbabbitt> RESOLVED: used line count is capped by the number of items<br> <kbabbitt> aaronei: follow up, might we add a property that allows either option?<br> <kbabbitt> TabAtkins: yes that's possible in the future<br> <kbabbitt> TabAtkins: final easy one here, balance-reverse<br> <fantasai> s/aaronei/arronei/<br> <kbabbitt> ... everyone okay with that or do we need to spell differently<br> <kbabbitt> ... normally your first line is at cross start side and they stack inward this makes them stack opposite<br> <kbabbitt> fantasai: I think we should just say balance wrap reverse<br> <kbabbitt> TabAtkins: that's the other possibility but it suggests balance-wrap<br> <kbabbitt> iank_: I think that's fine<br> <kbabbitt> TabAtkins: I'm fine either way<br> <fantasai> s/balance-wrap/balance wrap/<br> <kbabbitt> ... would be less fine if we were still doing no-wrap<br> <kbabbitt> Rossen: balance wrap reverse?<br> <fantasai> flex-wrap: nowrap | [ wrap | wrap-reverse] || balance<br> <astearns> s/say balance wrap reverse/say balance wrap-reverse/<br> <kbabbitt> iank_: yes<br> <kbabbitt> Rossen: objections?<br> <astearns> +1<br> <kbabbitt> RESOLVED: flex-wrap: nowrap | [ wrap | wrap-reverse] || balance<br> <kbabbitt> TabAtkins: final one is the first thing, core proposal, flex-line-count taking an integer and a function<br> <kbabbitt> ... that calculates a number of columns out of available space<br> <kbabbitt> ... are we okay with that?<br> <kbabbitt> fantasai: it's a cool idea, what I'm struggliing with is getting us to a point where multicol, and flex, and ideally also grid have some way of expressing same concepts in same ways<br> <kbabbitt> ... instead of different way s which is where this proposal is getting us to<br> <astearns> q+<br> <kbabbitt> ... don't have a counter proposal but would be helpful from a design perspective if we can make ways of expressing this consistent<br> <kbabbitt> TabAtkins: part of the proposal is taht we add this to column-count as well<br> <kbabbitt> ... could express multicol and flex in same way<br> <kbabbitt> ... better because you get more functionality out of this<br> <iank_> `column-count: 3; column-width: 100px` is very confusing to what it does<br> <kbabbitt> ... gives us ability to clamp to max count in multicol which you can't do today<br> <iank_> q+<br> <kbabbitt> fantasai: had another question, dont' functions in calc need to compute?<br> <kbabbitt> TabAtkins: don't need to compute, can resolve at any time<br> <kbabbitt> fantasai: where else do we have that?<br> <kbabbitt> TabAtkins: percentages in layout<br> <kbabbitt> fantasai: but your count is still down to a length or percentage<br> <kbabbitt> ... this can't be resolved down to that<br> <kbabbitt> TabAtkins: calc-size cant resolve until layout either<br> <kbabbitt> fantasai: that can be put inside calc?<br> <kbabbitt> TabAtkins: yes just a math function<br> <Rossen> ack astearns<br> <kbabbitt> astearns: I would rather see this as a separate issue<br> <kbabbitt> ... to consider it a little more before we decide<br> <kbabbitt> ... I do like the idea of using this functionality in more places<br> <kbabbitt> ... dividing a length by another length seems generally useful<br> <kbabbitt> TabAtkins: you can already do that everywhere by calc()<br> <kbabbitt> ... trick here is you have access ot information the property doesn't natively have access ot<br> <kbabbitt> astearns: would like to surface other use cases for this and see if we can come up with something that can be generally applied<br> <kbabbitt> TabAtkins: ok with deferring this functionality, fantasai wanted to make sure we could do flex lines by size<br> <kbabbitt> ... okay deferring<br> <Rossen> ack iank_<br> <kbabbitt> iank_: the interaction between column-count 3 and column-width 100px is very confusing<br> <kbabbitt> ... I always have to check it<br> <kbabbitt> ... because column-width doesn't mean columns are set to that width, it means something else<br> <kbabbitt> ... this is more explicit for what author is doing vs 2 properties in flex<br> <kbabbitt> ... it's confusing in multicol, even when just using column-width<br> <kbabbitt> ... but I'm happy to resolve on just flex-lines-count and consider autofill behavior later<br> <kbabbitt> TabAtkins: that's consistent with us deciding later if we want to copy multicol<br> <kbabbitt> ... we are wide open if we defer the line sizing bit until later<br> <kbabbitt> Rossen: but you still want to resolve on line count?<br> <kbabbitt> TabAtkins: yes we need to resolve on that, core use case<br> <kbabbitt> ... doesn't work in practice without that<br> <kbabbitt> Rossen: resolve on line-count taking integer, work on rest later?<br> <kbabbitt> TabAtkins: yup<br> <kbabbitt> Rossen: objections?<br> <kbabbitt> RESOLVED: flex-line-count: <integer>, will work on rest later<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/13414#issuecomment-4172022385 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:09:36 UTC