text-wrap: pretty

[kojiishi]

Hello TAG!

I'm requesting a TAG review of text-wrap: pretty.

This feature adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.) This is another value of the text-wrap property, once reviewed for balance at #822.

• Explainer¹ (minimally containing user needs and example code): url
• Specification URL: spec url
• Tests: wpt folder(s), if available (note this contains both balance and pretty)
• User research: [url to public summary/results of research]
• Security and Privacy self-review²: [url]
• GitHub repo (if you prefer feedback filed there): [url]
• Primary contacts (and their relationship to the specification):
  • @kojiishi (Implementer), @bfgeek (Implementer), @fantasai (Spec Editor)
• Organization(s)/project(s) driving the specification: Google
• Key pieces of existing multi-stakeholder review or discussion of this specification:
• External status/issue trackers for this specification (publicly visible, e.g. Chrome Status): https://chromestatus.com/feature/5145771917180928

Further details:

• I have reviewed the TAG's Web Platform Design Principles
• Relevant time constraints or deadlines: Implementation complete.
• The group where the work on this specification is currently being done: CSSWG
• The group where standardization of this work is intended to be done (if current group is a community group or other incubation venue): CSSWG
• Major unresolved issues with or opposition to this specification:
• This work is being funded by: Blink implementation is being done by Google.

💬 leave review feedback as a comment in this issue and @-notify [github usernames]

[fantasai]

@LeaVerou asked me to explain this feature and the potential compat impact etc.

This feature adjusts line breaking to avoid a short single word on the last line (also known as typographic orphans.)

This is not an accurate description. The text-wrap: pretty value is defined to ask the UA to apply more resources into line-wrapping and justification in order to make the text look “prettier”. The concerns that this is expected to balance include

• reducing the raggediness of the lines (reducing variance in their lengths), which makes the end edge look more even when not justified, and reduces the variation in justification space adjustments between lines when fully justified, thus improving readability as well as aesthetics
• avoiding rivers
• applying smarter line-breaking prioritization, to avoid awkward breaks
• etc.

Avoiding too-short last lines is certainly one aspect that can be considered by a UA for text-wrap: pretty, but it's only one of the things we expect the UA to consider. So while an implementation that only adjusts the last line length in response to text-wrap: pretty would be conformant to the spec (which gives a lot of leeway on interpreting pretty), it's a limited interpretation.

This presents a risk that authors, who really really want last-line length adjustment, will interpret text-wrap: pretty as a “make the last line length less short” control rather than “do lots of different expensive things to make it prettier”. I'm not entirely sure of the compat impact of that going forward, it might not be much. I am fairly sure, however, that it will create some confused messaging when the feature is evangelized, though, as it will be taught as “use this weird hack to fix your too-short last lines”.

I'll note there's also been discussion over the years of having a specific control for last line length; there's no draft yet because implementations weren't interested until now. But we do have the possibility of providing a specific feature for this specific implementation feature, and that may be a better path forward for this feature request.

[LeaVerou]

Hi there,

We looked at this in the plenary on Wednesday.

In general, we recommend explainers to be in Markdown, and are in the process of merging guidance to that effect in the Explainer Explainer.
Some more reasons for this in w3ctag/tag.w3.org#30 (comment) .

We were also a little confused about the name, since it seems that this feature is about controlling orphan words and pretty is very generic, which is why I reached out to @fantasai for clarification after the call.

If the intent of the spec is to have many varied heuristics into making text wrapping more aesthetically pleasing, I am a little worried about whether the current implementation can evolve into this eventually. I can easily see authors starting to use it as a property to control orphans, and before we know it, we can’t change it due to web compat.
The way authors are already evangelizing it so far confirms these fears.

If all this property does is prevent orphan words, I wonder if a property to control exactly that would be preferable, possibly as a longhand of text-wrap (text-wrap-orphans?). This could also give authors more control, and would be far more discoverable.

(To clarify, everything using first singular is my personal opinion, and does not necessarily reflect TAG consensus — I use first plural to express that)

[kojiishi]

If all this property does is prevent orphan words

To clarify Blink's intent, this property value should be able to do more, but the initial implementation in Blink focused on preventing orphaned words. Please see the discussion in Blink I2S and the "Overview" section of the design doc. Blink is planning to add more typographic improvements to the pretty algorithm incrementally.

[LeaVerou]

To clarify, I think it's ok for it to ship with fewer heuristics and evolve over time, but it needs to implement at least two to avoid authors using it as a proxy for a more specific thing.

[kojiishi]

That's a very good point, thank you. We saw many strong feedback on avoiding orphans from web developers (example 1, 2) and it wasn't easy to determine the next strong request from the feature candidates.

But it's also not difficult to pick one more feature, if we put the request priority aside. I'll think about it.

[LeaVerou]

It may still be a good idea to expose orphans via a more targeted property as well, e.g. see this issue about a property specifically about orphans. That would satisfy the golden rule of API design: common things should be easy, complex things should be possible.

[kojiishi]

Yes, thank you, we're aware of the resolution at csswg#3473.

RESOLVED: Add a control that is either a property or a value that causes UAs to make the last line longer than it would've originally done unless that was a bad idea

We're willing to support the new value once the syntax is finalized.

[kojiishi]

From our prototypes, adjusting hyphenation penalties under certain conditions seems doable without hitting the performance much, so I'm planning to add it to pretty, while keeping the new value only for typographic orphans.

[LeaVerou]

Hi Koji,

We discussed this today in a breakout. This sounds like a plan. It may be good to try and ship orphan control at the same time as text-wrap: pretty to further avoid the possibility of developers using this as a proxy for orphan control.

We think the specific heuristics to employ are better decided within the CSS WG (not necessarily as a normative part of the spec), however we'd recommend the multiple heuristics employed by text-wrap: pretty are in the same "caliber", i.e. not something major like orphan control plus something that seems minor from the authors' point of view, otherwise it may still be used as a property for orphan control, with the understanding that it also "has some quirks", especially if it's the only way to do orphan control in CSS.

[kojiishi]

Thank you for commenting to the issue, that helps.

For your second part, sorry I don't understand what the neuance of "caliber" is, please disregard if I seem to misunderstand, but if you consider hyphenation is minor and you're looking for some other major features in Knuth-Plass, it may be difficult. The 3 top areas Knuth-Plass can improve are hyphenation, justification, and typographic widows/orphans control. For example, w3c/csswg-drafts#672 has 8 candidate improvements, 3 are about typographic widows/orphans, 2 are about hyphenations, and 3 are about justification. Another example, this article expects pretty to improve typographic widows/orphans and better spacing, and "better spacing" is more important when the text is justified.

I fully agree having a separate control for typographic orphans is good, but if pretty means using more sophisticated non-greedy algorithms such as Knuth-Plass, I think it's reasonable to expect its outcome is minimizing typographic widows/orphans plus minor features, if we consider hyphenation and justification are minor.

[LeaVerou]

Thanks for bearing with us - we realize this response is late.

There's no way to quantify what is minor, the end goal is to ensure that authors do not use this as a proxy for a single feature (preventing orphans) which would prevent it from including more heuristics in the future. So in addition to preventing orphans, the property should control at least one more factor that is noticeable in common usage.

Preventing "rivers of white space" in justified text is certainly not minor, but we'd love to also see something that makes a visible difference in other text alignment modes as well.

Again, this becomes less of a concern if lower level control over orphans ships at the same time (or earlier).

Also - can you please elaborate on the multi-implementer support - we see that the Chrome Status page lists Webkit and Mozilla as positive but does not link to standards positions.

[plinss]

Hi @kojiishi any response to Lea's questions above?

[hober]

@kojiishi what about @LeaVerou's other questions?

[hober]

The TAG looked at this again in a breakout today, and we returned to the naming issue. The name pretty doesn't convey to authors that this feature is computationally expensive, which may lead to more widespread adoption than is desirable, which will harm the real-world performance of sites. (That is, text-wrap: pretty is an attractive nuisance.) This concern isn't theoretical: consider this social media post encouraging authors to unconditionally apply text-wrap: pretty to everything:

💡 CSS Tip!

Enhance your text wrapping using two lines of code. No more lonely words at the end of paragraphs, and titles will look much better.

Will you add this to your CSS reset?

* {
  text-wrap: pretty;
}
h1,h2,h3,h4,h5,h6 {
  text-wrap: balance;
}```

If this feature gets over-adopted by authors eager to improve their sites, to the point where it starts affecting benchmark scores, browser engines will be disincentivized to implement text-wrap: pretty as anything other than an alias for text-wrap: auto, reducing the utility of the feature to zero.

We encourage the working group to rename the property value to something that reflects its costs as well as its benefits.

[hober]

@kojiishi @bfgeek @fantasai, has there been any further discussion of the above issue in the CSS WG?

[jyasskin]

I've filed w3c/csswg-drafts#10785 to encourage the CSSWG to discuss the naming question. My sense from the discussion today was that the TAG will accept the CSSWG's expertise on this issue, as long as they've actually considered it. I also got the sense that including hyphenation in text-wrap: pretty's behavior (as Chrome has now) is sufficient to avoid the concern that this property will be used as a way to just control orphans, especially given the evidence that at least some authors do notice the change in hyphenation behavior.

[tabatkins]

As noted in w3c/csswg-drafts#10785, it's been a year since the original TAG review request; at this point it's far too late to do naming changes unless something is genuinely broken (which I think it's clear isn't the case here).

[jyasskin]

While we recognize that the author pain points this is designed to solve are real and prominent, we still have several concerns about this solution, both in terms of its current definition, and its timing.

In general, shipping high level features is a good idea when
a) we have a good idea of what a good solution to author needs would be (either by first shipping low level features and observing how they are used OR because the solution is so obvious that this step is not needed) or
b) the corresponding low-level features would be very tedious to use to produce the same result.

In this case, neither of these appear to be true: we do not have a good sense of what text-wrap: pretty should end up doing in the end, and it currently only corresponds to two very specific features, that would not be tedious to set individually.

One author's reaction to this feature appears to validate this concern: they wanted control over orphans and are frustrated they have to accept re-hyphenation to get it.

Given this, we are concerned that the behavior of this feature will need to change a lot over time, and that after a certain amount of adoption, those changes will either break web compatibility, or will require a high enough performance cost that browsers won't be able to ship them. We encourage the CSSWG to:

1. keep working to expose the lower-level features so authors can request them directly (e.g. if their intent is to avoid orphans, they should be able to express this without having to resort to a feature that combines it with other things).
2. work on a plan to ensure that implementations can eventually ship a truly-pretty line-wrapping algorithm even if that turns out to be expensive.
3. consider whether the completely open-ended specification for text-wrap: pretty ("Specifies the UA should bias for better layout over speed, and is expected to consider multiple lines") was the right way to get engines to ship evolvable and eventually-compatible implementations.

We think the CSSWG is the right place to pursue those goals and that parallel discussion within the TAG won't help anyone. Thus, we're closing this as Resolution: unsatisfied with the acknowledgement that solving the above problems would likely turn this into a satisfied resolution.