LGTM2 On Thu, May 28, 2026 at 3:27 PM Mike Taylor <[email protected]> wrote:
> LGTM1 > On 5/28/26 2:27 p.m., 'Alison Maher' via blink-dev wrote: > > > I'll add some rudimentary ones next week. Broadly speaking it shouldn't > affect our existing fragmentation logic at all. Balancing just picks > different line break-points, so can rely on our existing logic for wrapping > flexboxes. Nothing else further than line-breaking changes. > > Sounds good! Yeah, fwiw, I personally wouldn't consider this one a > blocker. Since we just store the unfragmented offsets, and then adjust them > for fragmentation if needed, this should just work as-is (and just be a > matter of adding basic test coverage and coverage for some of the weird > expansion edge cases that could lead to an unbalanced final result). > > Thanks, > Alison > On Thursday, May 28, 2026 at 11:12:33 AM UTC-7 [email protected] > wrote: > >> Thanks Alison! >> >> On Thu, May 28, 2026 at 11:00 AM 'Alison Maher' via blink-dev < >> [email protected]> wrote: >> >>> Hi Ian, >>> >>> Super excited to see this rolling out! >>> >>> I had a quick question about the missing Web Feature ID. I didn't see a >>> request <https://github.com/web-platform-dx/web-features/issues> filed >>> for it. I suspect it would make sense to assign a temporary ID for this new >>> functionality until it’s more broadly available (separate from the general >>> flexbox ID)? >> >> >> Filed under https://github.com/web-platform-dx/web-features/issues/4081 >> >> >>> >>> Also, re: WPTs, do we have any coverage for 'flex-wrap: balance' in >>> fragmentation scenarios (perhaps in another folder?) >>> >>> Based on how flex fragmentation is implemented, I suspect it should just >>> work out of the box, but some cases that may be interesting to test would >>> be in forced break scenarios where lines can end up expanding. I suspect we >>> don't want to re-run layout in those cases and accept that it may not be >>> fully balanced in the end? >>> >> >> I'll add some rudimentary ones next week. Broadly speaking it shouldn't >> affect our existing fragmentation logic at all. Balancing just picks >> different line break-points, so can rely on our existing logic for wrapping >> flexboxes. Nothing else further than line-breaking changes. >> >> >>> Thanks, >>> Alison >>> >>> On Wednesday, May 27, 2026 at 9:35:39 AM UTC-7 Chromestatus wrote: >>> >>>> *Contact emails* >>>> [email protected] >>>> >>>> *Explainer* >>>> https://github.com/bfgeek/flex-wrap-balance >>>> >>>> *Specification* >>>> https://drafts.csswg.org/css-flexbox-2 >>>> >>>> *Summary* >>>> flex-wrap:balance allows developers to distribute content between >>>> flex-lines so that it appears more balanced (similar to text-wrap:balance). >>>> >>>> *Blink component* >>>> Blink>Layout>Flexbox >>>> <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3ELayout%3EFlexbox%22> >>>> >>>> *Web Feature ID* >>>> *No information provided* >>>> >>>> *Motivation* >>>> Without balancing it is trivial to create flex-lines which appear >>>> "unablanced" (lots of whitespace in a particular line). This often makes >>>> developers avoid wrapping flexboxes, instead allowing content to overflow. >>>> See explainer. >>>> >>>> *Initial public proposal* >>>> https://github.com/w3c/csswg-drafts/issues/3070 >>>> >>>> *TAG review* >>>> https://github.com/w3ctag/design-reviews/issues/1227 >>>> >>>> *TAG review status* >>>> Issues addressed >>>> >>>> *Goals for experimentation* >>>> None >>>> >>>> *Risks* >>>> >>>> >>>> *Interoperability and Compatibility* >>>> Interoperability risk: Other browsers do not implement. >>>> >>>> *Gecko*: No signal ( >>>> https://github.com/mozilla/standards-positions/issues/1405) >>>> >>>> *WebKit*: No signal ( >>>> https://github.com/WebKit/standards-positions/issues/660) >>>> >>>> *Web developers*: Positive ( >>>> https://bsky.app/profile/una.im/post/3lpcjcjn4w22r) >>>> >>>> *Other signals*: >>>> >>>> *Activation* >>>> Unlike other CSS features, this may be adopted incrementally by >>>> web-developers as it "gracefully degrades" if not supported. We saw this >>>> previously with `text-wrap:balance` for example. >>>> >>>> *Security* >>>> None. >>>> >>>> *WebView application risks* >>>> >>>> Does this intent deprecate or change behavior of existing APIs, such >>>> that it has potentially high risk for Android WebView-based applications? >>>> *No information provided* >>>> >>>> >>>> *Debuggability* >>>> Small CSS addition. >>>> >>>> *Will this feature be supported on all six Blink platforms (Windows, >>>> Mac, Linux, ChromeOS, Android, and Android WebView)?* >>>> Yes >>>> >>>> *Is this feature fully tested by web-platform-tests >>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>?* >>>> Yes >>>> https://wpt.fyi/results/css/css-flexbox/balance >>>> >>>> *Flag name on about://flags* >>>> experimental-web-platform-features >>>> >>>> *Finch feature name* >>>> FlexWrapBalance >>>> >>>> *Rollout plan* >>>> Will ship enabled for all users >>>> >>>> *Requires code in //chrome?* >>>> False >>>> >>>> *Tracking bug* >>>> https://issues.chromium.org/issues/416755656 >>>> >>>> *Measurement* >>>> WebDXFeature::kFlexWrapBalance >>>> >>>> *Estimated milestones* >>>> Shipping on desktop 150 >>>> DevTrial on desktop 149 >>>> Shipping on Android 150 >>>> DevTrial on Android 149 >>>> Shipping on WebView 150 >>>> >>>> *Anticipated spec changes* >>>> >>>> Open questions about a feature may be a source of future web compat or >>>> interop issues. Please list open issues (e.g. links to known github issues >>>> in the project for the feature specification) whose resolution may >>>> introduce web compat/interop risk (e.g., changing to naming or structure of >>>> the API in a non-backward-compatible way). >>>> *No information provided* >>>> >>>> *Link to entry on the Chrome Platform Status* >>>> https://chromestatus.com/feature/4547107962486784?gate=6499348504117248 >>>> >>>> *Links to previous Intent discussions* >>>> Intent to Prototype: >>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/67eae2d6.170a0220.8108a.099e.GAE%40google.com >>>> >>>> >>>> This intent message was generated by Chrome Platform Status >>>> <https://chromestatus.com>. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "blink-dev" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To view this discussion visit >>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f227ac9-9a92-450f-92be-532fa843b877n%40chromium.org >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8f227ac9-9a92-450f-92be-532fa843b877n%40chromium.org?utm_medium=email&utm_source=footer> >>> . >>> >> -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b910ea8d-a4f8-4c05-9134-00c1947d0618n%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b910ea8d-a4f8-4c05-9134-00c1947d0618n%40chromium.org?utm_medium=email&utm_source=footer> > . > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8b3b90e1-8c9e-4331-8735-8f9e3cf409da%40chromium.org > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/8b3b90e1-8c9e-4331-8735-8f9e3cf409da%40chromium.org?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADsXd2MOCP51fcYVObroefm3ijnkbxLPMGXoV%3DJdRQ0S2PZgqw%40mail.gmail.com.
