#1227: WG New Spec: "flex-wrap:balance"

Visit on Github

Opened May 8, 2026

Specification

https://drafts.csswg.org/css-flexbox-2/

Explainer

https://github.com/bfgeek/flex-wrap-balance/blob/main/README.md

Links

  • The WG's request for this TAG review:

???

  • Previous early design review, if any:

N/A

  • An introduction to the feature, aimed at unfamiliar audiences:

https://github.com/bfgeek/flex-wrap-balance/blob/main/README.md#flex-wrapbalance-explainer

This allows developers to "balance" flex-lines, (similar to text-wrap:balance).

  • A description of the problems that end-users were facing before this proposal:

https://github.com/bfgeek/flex-wrap-balance/blob/main/README.md#flex-wrapbalance-explainer

For a wrapping flexbox, developers would often be left with a single flex-item on the last line, which is often undesirable.

Developers were often working around this issue by converting a flexbox to inline-layout (to use text-wrap:balance instead), and making all the flex-items display:inline-block. This meant that they'd "lose" flexbox features limiting potential designs.

Other workarounds included:

  • Detecting when there were "orphans" on the last flex-line, then adding margin on an appropriate flex-item.
  • Bisecting via script the flexbox size.
  • Using media-queries/container-queries to hardcode margins to "balance".
  • etc.

Developers also rely on multi-col (see wikipedia "references" section in desktop mode). Developers can re-create this using flexbox, and flex-direction: column; flex-wrap:balance; flex-line-count: 2;. Balancing flexbox will generally be less overhead (less time spent within out) then multi-col helping low end devices significantly.

  • Alternatives considered:

https://github.com/bfgeek/flex-wrap-balance/blob/main/README.md#alternatives

There aren't too many other potential avenues; others were discussed but flex-wrap:balance is the most natural extension and what developers expect.

There is an extension point that is left unsolved at the moment (see: https://github.com/w3c/csswg-drafts/issues/13414#issuecomment-4101156045 ), but the current design doesn't constrain solving this in the future. (We'd need the flex-line-count property either way).

  • Examples of how to use the proposal to solve the end-users' problems:

https://stackoverflow.com/questions/20729201/navigation-with-balanced-css-flex-wrap-containers https://bsky.app/profile/yisibl.bsky.social/post/3m6jksgovdk2c https://odland.dev/2024/12/22/web-wish-22-flex-wrap-balance.html https://nerdy.dev/css-wishlist-2025#flex-wrap-balance https://bsky.app/profile/una.im/post/3lpcjcjn4w22r https://bfgeek.com/flexbox-image-gallery/

  • What do the end-users experience with this proposal:

Joy that a 10+ year feature request is available on the web platform.

  • User research you did to validate the problem and/or design, if any:

A lot of reading existing issues that developers were running into, and the various tricks they were using to try and solve this problem. Many developers came to a similar solution space.

  • Web Platform Tests:

https://wpt.fyi/results/css/css-flexbox/balance (they'll be there soon).

The specification

Where and by whom is the work is being done?

  • GitHub repo:

https://github.com/w3c/csswg-drafts

  • Primary contacts:

    • Ian Kilpatrick @bfgeek , Google Chrome, Implementor
    • Tab Atkins @tabatkins , Google Chrome, Specification Editor

  • Organization/project driving the specification:

Google Chrome

  • This work is being funded by:

Google Chrome

  • Primary standards group developing this feature:

CSSWG

  • Incubation and standards groups that have discussed the design:

CSSWG

Feedback so far

This not really a major issue but - see above wrt. "column-width" feature. Current solution space doesn't constrain in a negative way. See: https://github.com/w3c/csswg-drafts/issues/13414#issuecomment-4172022385

RESOLVED: flex-line-count: <integer>, will work on rest later

You should also know that...

This is a relatively small but highly requested additional to flexbox layout. Many web-developers have run into this problem over the years.

Flexbox Level 1 is a very stable spec, hence being added into Level 2.

<!-- Content below this is maintained by @w3c-tag-bot -->

Track conversations at https://tag-github-bot.w3.org/gh/w3ctag/design-reviews/1227

Discussions

Comment by @nico3333fr May 12, 2026 (See Github)

Kinda agree: this would be an nice addition, I often get the comment: could you balance these contents like you do on the text?

Could be a nice addition :)

Comment by @jyasskin May 20, 2026 (See Github)

Thanks for sending us this review. We've decided not to do a detailed review, since this is similar enough to existing features, like flex-wrap and text-wrap:balance that it doesn't look like it would introduce any new architectural concerns. We're glad to see that the CSSWG is actively working on it, and we appreciate the work you put into writing this explainer and filing this review. We do have 2 comments on your explainer:

  1. Explainers should generally live next to their specifications rather than in personal repositories. So inside https://github.com/w3c/csswg-drafts/tree/main/css-flexbox-2 would be ideal.
  2. We'd like explainers to always include the 4 Considerations sections, even if the content is "this feature/use case/design has no privacy implications." That confirms to readers that you did actually consider whether there were implications.