Intent to prototype: CSS text-wrap:balance

131 views
Skip to first unread message

Jonathan Kew

unread,
Sep 5, 2023, 2:52:20 PM9/5/23
to dev-pl...@mozilla.org
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

Specification:
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

Other browsers:
Blink: shipping (since about 114, I believe)
WebKit: WIP, see 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.

Nicolas Chevobbe

unread,
Sep 6, 2023, 2:06:15 AM9/6/23
to dev-pl...@mozilla.org, jfkt...@gmail.com
This is exciting!

The spec says:

> UAs may treat this value as 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.

Jonathan Kew

unread,
Sep 6, 2023, 4:50:20 AM9/6/23
to Nicolas Chevobbe, dev-pl...@mozilla.org
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
Reply all
Reply to author
Forward
0 new messages