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.

Reply via email to