[css-pseudo] Proposal: Add `text-wrap: balance` to supported `::cue` properties

[argyleink]

Seems like a perfect fit and could even be a UA default style addition.

• lines never go over 3 lines
• already has a max inline size style
• balanced text is more pleasing to the eye
• balanced text would have less widows

I went to prototype the thought this morning and remembered there's an allow list for ::cue and that this style would be thrown away as it's not in the list.

[dbaron]

Is the current spec for this https://w3c.github.io/webvtt/#the-cue-pseudo-element ? If so, maybe the issue belongs in the webvtt repo?

That said, none of the other properties in the current allow-list seem this tied to layout.

I'd also note that the allow list is properties, not values, and it's not clear to me if the wrap | nowrap distinction is desirable for cues.

[nigelmegitt]

Using a rendered-length basis for text-wrap: balance likely works okay for paragraphs of text in long columns, but is probably the wrong choice for cues used for subtitles or captions, that are typically a small number, e.g. 2 or 3, sometimes 4, lines long.

Instead, for the subtitle and caption use case:

• text needs to be broken into "blocks" that are each short groups of lines, where each block appears consecutively in time
• both the blocks and the lines in the blocks should be broken based on grammatical structure, e.g. using natural language processing, though the blocks themselves need also to be chosen based on the timing of associated audio

An example of editorial guidance for this problem in English can be found in the BBC Subtitle Guidelines section "Break at natural points"

The solution space for this could be one of several different options:

1. Authors divide the text into blocks, and the blocks into lines, inserting manual line breaks;
2. Authors divide the text into blocks without manual line breaks, and the renderer divides the blocks into lines;
3. Authors provide transcripts with word by word, or phrase by phrase, timings, and the renderer divides the transcripts into blocks, and the blocks into lines.

Of these options, 1 and 2 are currently the typical approach, that is essentially encoded into WebVTT and TTML. Option 3 could ultimately be a more accessible and elegant approach, but has only been demonstrated in prototype form some years ago, documented in BBC R&D White Paper 295, and not adopted more broadly.

Option 1 is the most robust as long as the text size is not increased after authoring, since that can introduce additional line breaks. It does not need text-wrap: balance.

Option 2 is the one where something like text-wrap: balance could be most useful, but not if the algorithm is purely looking at line length.

[frivoal]

I'd also note that the allow list is properties, not values, and it's not clear to me if the wrap | nowrap distinction is desirable for cues.

Luckily, there's now a dedicated property, which is a longhand of text-wrap, and doesn't include the wrap|nowrap distinction: https://drafts.csswg.org/css-text-4/#text-wrap-mode (thought note that this is being bikesheded #9102 (comment))

[frivoal]

I wonder if this should be addressed by: (a) letting balance be a bit smarter and take some measure of grammar into account, or (b) keeping balance as a fairly mechanical thing, but use it in combination with word-break: auto-phrase (while making sure it also applies its phrase finding to space separated languages).

[nigelmegitt]

(b) seems like an elegant solution, in principle, though I wonder if we can implement it so that it is clear to authors how to get the behaviour they want. Are we really looking at word break opportunities, and their prioritisation? I'm willing to be persuaded either way, from a semantic viewpoint.

From an implementer perspective, is it okay to have a potentially complex interaction between multiple properties that all affect the same layout process? I guess there are already other inputs to the process, like font size, so in principle this is not a new idea, but the two things seem so closely related that I'm not sure.

Perhaps there's a (c) add a new property value grammatical-balance that could address both these questions?