@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.

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)

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

Sorry for late, filed them here:
mozilla/standards-positions#993
WebKit/standards-positions#324

@kojiishi what about @LeaVerou's other questions?

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.