On 06/09/2023 02:06, Nicolas Chevobbe wrote:
This is exciting!

The spec says:

> UAs may treat this value as auto <https://drafts.csswg.org/css-text-4/#valdef-text-wrap-style-auto> if there are more than ten lines to balance.

It would be helpful for web developers to be aware of this by showing some notice in the DevTools Inspector Rules view. I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1851756 , but let me know if we don't plan to have such restriction in Gecko.

Yes, I do expect to have a limit on the number of lines that we'll attempt to balance; this is because balancing across a large number of lines could become computationally expensive -- think O(n²) -- and is unlikely to be all that useful in practice.

FWIW, the current Chrome release appears to limit balancing to 4 lines before reverting to normal line-breaking; in Canary, they've increased this to 6, but still short of the 10 mentioned in the spec. My WIP patch for Gecko uses a cutoff of 10 lines, as per spec, but if Blink pushes for a lower limit I guess the spec might get adjusted here.

Anyhow, an indication in the Inspector where `balance` is being ignored because the block is too long does sound like an interesting idea; thanks for filing that!

JK



On Tuesday, September 5, 2023 at 8:52:20 PM UTC+2 [email protected] wrote:

    Summary:

    The `text-wrap: balance` property can improve the layout of short
    blocks
    of text (a few lines, such as a long headline) by adjusting the line
    lengths to be more consistent.

    ...which could become:

    The `text-wrap: balance` property can improve the layout of
    short blocks of text (a few lines, such as a long headline)
    by adjusting the line lengths to be more consistent.


    Bug:
    https://bugzilla.mozilla.org/show_bug.cgi?id=1731541
    <https://bugzilla.mozilla.org/show_bug.cgi?id=1731541>

    Specification:
    https://drafts.csswg.org/css-text-4/#text-wrap-style
    <https://drafts.csswg.org/css-text-4/#text-wrap-style>
    [see note below]

    Standards Body:
    W3C CSS Working Group

    Platform coverage:
    all

    Preference:
    layout.css.text-wrap-balance.enabled

    DevTools bug:
    n/a

    Link to standards-positions discussion:
    https://github.com/mozilla/standards-positions/issues/755
    <https://github.com/mozilla/standards-positions/issues/755>

    Other browsers:
    Blink: shipping (since about 114, I believe)
    WebKit: WIP, see https://bugs.webkit.org/show_bug.cgi?id=259958
    <https://bugs.webkit.org/show_bug.cgi?id=259958>

    web-platform-tests:
    /css/css-text/white-space/text-wrap-balance-*


    [note]
    Initially, I propose to implement a simple `text-wrap` longhand
    property, to support the `text-wrap: balance` usage that is quickly
    becoming popular. This corresponds to what Blink currently supports.

    The CSS Working Group has resolved to restructure both the
    `white-space`
    and `text-wrap` properties to become shorthands, with `balance`
    becoming
    a value of the `text-wrap-style` longhand. This will be a
    backward-compatible update, as `text-wrap` will become a shorthand and
    will still accept the `balance` keyword.

    The restructuring of `white-space` (and associated conversion of
    `text-wrap` to a shorthand) has the potential to be a bit risky, given
    the number values involved and the complexity of their interactions. In
    addition, final spec details are still under discussion, so it seems
    premature to proceed with this right now. So I propose to leave this
    for
    a separate task. But `text-wrap: balance`, as already implemented in
    Blink, is popular with web developers and it seems desirable to provide
    this in Gecko without delay.


--
You received this message because you are subscribed to the Google Groups 
"[email protected]" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion on the web visit 
https://groups.google.com/a/mozilla.org/d/msgid/dev-platform/38d2a6b4-cdd5-9a0f-71f5-18aaa3f96a99%40gmail.com.

Reply via email to