[css-text-4] Allow for paragraph-level line breaking

[litherum]

There are a few algorithms which attempt to choose line breaks within a paragraph in order to maximize the beauty of the paragraph as a whole. Such algorithms try to do some subset of:

• Minimize hyphenation
• Minimize extra space at the end of each line (or between words for justified text)
• Minimize rivers
• Minimize widows/orphans
• Minimize two hyphenated lines in a row
• Minimize visual differences between adjacent lines
• Minimize single-syllable or single-word last lines
• For paginated media, minimize single lines at the beginning or end of pages
• More?

Obviously, it is impossible to satisfy all these desires simultaneously for arbitrary paragraphs. The exact algorithm should not be specced for these reasons:

• Browsers should be allowed to innovate with heuristics of deciding how hard to try to solve one item at the expense of the other items
• Browsers should be allowed to teach and improve their implementations about new typographical conventions as time goes by
• Criteria for beautiful paragraphs are locale- and language-specific
• Different user agents may wish to provide different thresholds of participation (e.g. only consider a sliding window of n lines, or bail after x milliseconds of compute time, etc.)

Instead, there should be a way for a web author to opt-in to paragraph-level layout for beautiful paragraphs.

I'm not sure what the best mechanism for this is. Perhaps a new value to the text-wrap property? Perhaps a new property? Perhaps something else?

[frivoal]

Do you think there is anything in the specification currently preventing browsers from implementing paragraph-level layout already? I know they don't, but if they could, maybe we don't need an opt in at all, and any browser willing to go through the necessary implementation complexity can just turn it on by default.

[kojiishi]

I think he meant it to be an opt-in, since turning this on will hit the performance quite severely. Adobe InDesign has a concept of pluggable composer, and provide 4 different composers; combinations of English/Japanese and line/paragraph levels. AFAIU, the composer in InDesign provides line breaker and justification algorithm.

I like the idea, and I hope @astearns as well. I prefer a separate property, something like text-rendering, but I'm open to other ideas too.

[eaenet]

This is exciting and something I'd be very supportive of. Given the performance concerns though it'll likely have to be opt-in as suggested by both @litherum and @kojiishi.
It might also be possible to implement support of this on top of custom layout to allow for custom pluggable composers.

[litherum]

Do you think there is anything in the specification currently preventing browsers from implementing paragraph-level layout already?

@kojiishi is correct. It would be incorrect to do this automatically for both performance and correctness. Opting everything in automatically would be a performance regression, and the web would be upset if we just start changing every line break on every page to be dramatically different.

[astearns]

Line breaks aren't controlled directly by CSS anyway - line breaks change browser to browser and platform to platform and that's OK. So I think it would be fine for browsers to incrementally improve their line breaking without an opt-in.

But I agree that the performance characteristics of full-paragraph composers are likely to require an opt-in. InDesign doesn't actually go full-paragraph, it only does a set number of lines at a time. I think browsers should be able to experiment with composers, and even disagree about what works best. So an opt-in would probably need to be pretty generic, perhaps a single-line composer as a default and a multi-line composer as the opt-in.

[frivoal]

Point taken about performance. However I think if we introduce a switch, it should be between auto and on, not between off and on: CSS UAs generally do greedy line breaking as the default, and that's ok, but if an implementer wants to provide a better default (e.g. it is a print UA not concerned with performance, or it has a not-great-but-better-than-greedy algorithm that performs fine...), that should be allowed.

With that in mind:

• Do we want that switch at all, or should it be left to houdini? I think this should be baked in CSS. Certainly houdini APIs should be capable of supporting this, but doing it right in an i18n context is hard and tedious, and I don't think putting that burden on authors is reasonable.
• Do we want auto | on or auto | on | off, where off explicitly requires greedy line breaking? I don't think off is needed, but I could be wrong. Authors do not know enough about the performance tradeoff that this implies to make an informed decision (other than by assuming a particular version of a particular browser), and if they need to depend on a certain wrapping behavior, there's white-space: pre
• Do we want to be able to switch between multiple forms of smart line breaking? If the answer is “yes, but not until a later level”, does that still influence how we design the property?

[litherum]

Houdini should not be required to have beautiful paragraphs.

I also don't see a use case for off. Making auto the initial value is a good idea so browsers can improve their line breaking over time.

Eventually, adopting more customizability for smart paragraph breaking is totally reasonable in a later level. However, it's too early to spec something like that in this level. However, the keyword "on" is compatible because, in later levels, we could list additional keywords which would appear after the "on" value.

It sounds like Florian is leaning toward a new property. Therefore, the current proposal is:

paragraph-layout: auto | on
initial value: auto

Obviously we can bike-shed the name too.

[frivoal]

Right, that's kind of what I have in mind. At the same time, you suggestion to use text-wrap is quite reasonable also, as it seems the separate property would not do anything when text-wrap is nowrap or balance. so we could have a new value along the lines of text-wrap: smart or text-wrap: smart-wrap or text-wrap: contextual-wrap text-wrap: paragraph-wrap...

So, to decided if we need more values to the existing property or a new one:

• Which one gives the better fallback behavior when the new value/property is not supported, or when additional values are later added? Looks the same to me, in both case, you can use the cascade to provide your favorite fallback, and if you don't it falls back onto the default greedy approach
• Any compat constraint? I don't think so. AFAIK text-wrap is not implemented.
• Does the decision to wrap or not and the way to wrap look like separate decisions, that you may want to cascade separately? Maybe: you could decide to switch a the whole page to smart wrapping for any element that wraps, and pick between wrap and nowrap at a fine grained level. that would push for separate properties, but not that strongly, since text-wrap is inherited. You can still do :root { text-wrap: smart;} and selectively apply nowrap where it belongs.

All in all, I think I could go either way, but I now lean a bit more towards a value to text-wrap. And given that text-wrap has not been implemented anywhere yet I think, we can bikeshed the property name and existing values if needed to make everything fit better together.

[kojiishi]

I'd like to take my comments above "prefer a separate property" part back; i.e., I'm fine with a new value to text-wrap.

I see @litherum already expressed that either is fine with him, @frivoal @astearns do you have preference?

I admit I had wrong understanding on how text-wrap is defined currently, but now I understand it already behaves differently for inline and block.

So the block-level text-wrap chose line breaker while inline-level text-wrap turns on/off wrapping looks reasonable to me.

And given @astearns's suggestion above, keyword should be multiline rather than paragraph? Or do we prefer even more generic name, such as smart as suggested by @frivoal?

[kojiishi]

I missed the last paragraph of @frivoal so he already prefers a new value to text-wrap, so we're all good?

[litherum]

I think we're all good.

"Smart" is not a good name because it doesn't have any semantic meaning. I like Koji's "multi-line" idea because it is more accurate than "paragraph" (because I expect most implementations will do this in a sliding window rather than for the entire paragraph)

So the new proposal is:
text-wrap: wrap | nowrap | balance | multi-line
initial: wrap
where "multi-line" is a synonym for "wrap" when applied to inline elements.
Similar to "balance," the exact algorithm is UA-defined.

The conceptual difference between "balance" and "multi-line" is that "balance" is intended for titles where "multi-line" is intended for body text.

[astearns]

I don't think we need conf call time on this - I'll just edit the value in