- From: CSS Meeting Bot via GitHub <noreply@w3.org>
- Date: Thu, 29 Jan 2026 23:03:45 +0000
- To: public-css-archive@w3.org
The CSS Working Group just discussed `[css-flexbox-2] Add flex-wrap: balance;`, and agreed to the following: * `RESOLVED: Add balance keyword to flex-wrap` * `RESOLVED: try to, pending compat impact, for the purpose of flex line breaking, clamp the main size to 0` <details><summary>The full IRC log of that discussion</summary> <sgill> TabAtkins: 7.5 years ago i opened an issue asking for balance<br> <sgill> year or so ago ian started exploring an implementation. we have a mature one<br> <sgill> add a new value for the flex-wrap property<br> <iank_> `flex-wrap: nowrap | [ [ wrap | wrap-reverse ] || balance <integer [1,∞]>?]`<br> <sgill> add a balance keyword<br> <sgill> as part of line breaking we already have base size for line breaking<br> <sgill> iank_: can do it in O(nlogn) complexity<br> <sgill> TabAtkins: can also supply an integer to guarantee some number of lines<br> <sgill> e.g. wiki references section uses multicolumn to balance the references. somewhat expensive<br> <lea> q+<br> <astearns> q+<br> <sgill> one small bit we may want to correct<br> <sgill> currently for line wrapping flex items can become negatively sized<br> <sgill> allows the size of a flex line to not grow monotonically<br> <sgill> currently our implementation ignores that by clamping to 0<br> <sgill> it's a weird situation<br> <oriol> This is https://github.com/w3c/csswg-drafts/issues/12222<br> <sgill> may want to either resolve that for balancing flex items are clamped to base size of 0 and possibly go further<br> <sgill> by changing current flex spec. which would be a behavior change<br> <sgill> dholbert: not allowing this for the purposes of line wrapping?<br> <sgill> iank_: yes<br> <sgill> have not seen a case where you go past items<br> <sgill> two resolutions<br> <sgill> adding balance and figuring out the clamping behavior<br> <astearns> ack lea<br> <sgill> leaverou: still don't understand what the integer does<br> <sgill> TabAtkins: forces there to be at least that many flex lines<br> <dholbert> q+<br> <sgill> iank_: this is common if you would like to be balanced but at least be, for example, 2 lines<br> <sgill> leaverou: wonder if we could ship this later<br> <sgill> iank_: no. required to do the column case when you don't have a size to break against<br> <hober> q+<br> <sgill> TabAtkins: if you like at the wiki case. if they wanted to use balance they could do balance 2. without that column flexboxes would not balance since they do not have a height<br> <sgill> if you don't specify an integer you would like break and then balance<br> <astearns> ack astearns<br> <dholbert> q-<br> <sgill> leaverou: there are many use cases you want to balance a grid. instead of adding it to flex we create a separate property and shorthand flex/grid properties<br> <sgill> TabAtkins: they would have to be shipped at the same time<br> <oriol> q+<br> <sgill> iank_: grid case is not simple<br> <sgill> TabAtkins: any grid balancing we do we would probably want more controls<br> <sgill> leaverou: is there a way to pave the way forward?<br> <sgill> TabAtkins: we could just do a grid-wrap in the future<br> <astearns> ack fantasai<br> <sgill> iank_: we could always shorthand in the future but probably don't want to right now<br> <sgill> fantasai: we have a text-wrap property and it has a similar syntax<br> <sgill> good that the syntax is consistent<br> <sgill> in terms of integer, not sure it should be on the wrap property instead of its own<br> <sgill> this is case where it is similar to mulicol so maybe it would be better to match syntax there<br> <sgill> lots of cases where you know the number of columns you want but many don't want just want as many columns as can reasonably fit<br> <sgill> multicol has solved this<br> <sgill> reusing that here would mean the author gets familiar interface and powers<br> <lea> multicol has `column-fill: balance;`, but here it may not be column<br> <fantasai> I'm talking about `column-count` and `column-width`<br> <sgill> hober: in multicol you can specify column width and get as many columns as can fit. also count.<br> <lea> like `row-count`?<br> <sgill> both of your ideas together is you want the number to be in a different property and work similarly<br> <sgill> TabAtkins: i have minor objection. would require making flex lines a real line concept. so that they exist even if they are empty<br> <sgill> only have flex lines when there are items<br> <sgill> that's why number is part of balance<br> <sgill> having more control over flex lines, though, is interesting<br> <sgill> wouldn't say it's a bad thing to have it in. don't know if i want to solve it right nw<br> <lea> +1 fantasai<br> <sgill> fantasai: i think introducing the integer here may hinder future work<br> <sgill> TabAtkins: having guaranteed 2 columns seems to be a pretty core usecase<br> <sgill> astearns: not precluding solving that<br> <sgill> TabAtkins: we know people want to use it right now. should not push it off.<br> <sgill> astearns: agree adding the integer to flex-wrap would preclude changes to the future<br> <sgill> fantasai: don't think it works well to include it in the same property since it's a numeric value<br> <sgill> and flex wrap controls a bunch of other things<br> <sgill> seems like it should cascade independently<br> <astearns> q?<br> <astearns> ack hober<br> <sgill> hober: i just asked florian is there a compromise here? we do syntax tab wants and in the future if we add a new property we can retoraciveley do something?<br> <sgill> fantasai: no would be ugly<br> <sgill> TabAtkins: my idea is that the number of the flex lines would be the larger of the two<br> <sgill> fantasai: doesnt sound like great experience<br> <sgill> hober: worried about compat with the negative margin discussion<br> <sgill> iank_: don't think it would be much of a compat risk. happy to do it just for balance<br> <florian> q+<br> <astearns> ack oriol<br> <sgill> oriol: two questions.<br> <sgill> 1.) for example if you have 3 items and specify 5. you still get 3?<br> <sgill> iank_: yes<br> <astearns> maybe?<br> <sgill> 2.) reason provided for the number is the column flexbox case. when balancing text don't you have the same problem with orthogonal cases?<br> <sgill> TabAtkins: certainly same situation. but text is limited by the ICB<br> <sgill> probably applies somewhat but not strongly. would not object to explore something in that space<br> <astearns> ack fantasai<br> <astearns> ack florian<br> <sgill> florian: we think it's a bad fit because its numerical. idk why<br> <sgill> fantasai: sometimes when we have something that is a mode switch behavior and something in that area that is numerical we put them in separate properties to control them independently<br> <sgill> putting them in function notation does not get independent cascading and is awkward<br> <sgill> florian: unless i'm missing something the number here only works if you are in the balancing mode<br> <sgill> you are not choosing balance vs not balance independently with the lines<br> <sgill> fantasai: there are a whole bunch of other properties that don't apply if you don't turn this other thing on<br> <sgill> don't shove them together<br> <sgill> astearns: happy with resolving to add balance and decide how we want to add constraint later<br> <sgill> TabAtkins: that's fine. we think doing the number thing will be necessary for this feature<br> <sgill> PROPOSAL: Add balance keyword to flex-wrap<br> <sgill> RESOLVED: Add balance keyword to flex-wrap<br> <sgill> PROPOSAL: try to, pending compat impact, for the purpose of flex line breaking, clamp the main size to 0<br> <oriol> q+<br> <sgill> RESOLVED: try to, pending compat impact, for the purpose of flex line breaking, clamp the main size to 0<br> <astearns> ack fantasai<br> <astearns> ack oriol<br> </details> -- GitHub Notification of comment by css-meeting-bot Please view or discuss this issue at https://github.com/w3c/csswg-drafts/issues/3070#issuecomment-3820856620 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Thursday, 29 January 2026 23:03:45 UTC