It seems that the original spec had a more explicit intention:
>The pretty value is intended for body text, where the last line is expected to be a bit shorter than the average line.[0]
which seems to mainly be about avoiding short last lines. That is from a note. The actual value "specifies the UA should bias for better layout over speed, and is expected to consider multiple lines, when making break decisions," which is more broad. But the intent is clearly specified in the note. This is also how chrome described the feature as mentioned in the article. But it does say that the effect would change in the future:
>The feature does a little more than just ensure paragraphs don't end with a single word, it also adjusts hyphenation if consecutive hyphenated lines appear at the end of a paragraph or adjusts previous lines to make room. It will also appropriately adjust for text justification. text-wrap: pretty is for generally better line wrapping and text breaking, currently focused on orphans. In the future, text-wrap: pretty may offer more improvements.[1]
The design doc linked in [1] says this about it:
>The `text-wrap: pretty` is the property to minimize typographic orphans without such side effects.
>There are other possible advantages for paragraph-level line breaking, such as minimizing rivers. The csswg/#672 describes such other possible advantages. But the initial implementation focuses on typographic orphans, as it’s the most visible benefit, and to minimize the performance impacts.
>Because paragraph-level algorithms are slow, there are multiple variants to mitigate the performance impacts.[2]
The new draft[3] changed it to the current definition. What's also interesting from that new draft is this new note:
>The necessary computations may be expensive, especially when applied to large amounts of text. Authors are encouraged to assess the impact on performance when using text-wrap-style: pretty, and possibly use it selectively where it matters most.
which seems to go against what was written in the webkit blog. If developers start using this value everywhere expecting that it will be fast then that effectively stops future implementations from using a slower but better algorithm (assuming one exists).
>The pretty value is intended for body text, where the last line is expected to be a bit shorter than the average line.[0]
which seems to mainly be about avoiding short last lines. That is from a note. The actual value "specifies the UA should bias for better layout over speed, and is expected to consider multiple lines, when making break decisions," which is more broad. But the intent is clearly specified in the note. This is also how chrome described the feature as mentioned in the article. But it does say that the effect would change in the future:
>The feature does a little more than just ensure paragraphs don't end with a single word, it also adjusts hyphenation if consecutive hyphenated lines appear at the end of a paragraph or adjusts previous lines to make room. It will also appropriately adjust for text justification. text-wrap: pretty is for generally better line wrapping and text breaking, currently focused on orphans. In the future, text-wrap: pretty may offer more improvements.[1]
The design doc linked in [1] says this about it:
>The `text-wrap: pretty` is the property to minimize typographic orphans without such side effects.
>There are other possible advantages for paragraph-level line breaking, such as minimizing rivers. The csswg/#672 describes such other possible advantages. But the initial implementation focuses on typographic orphans, as it’s the most visible benefit, and to minimize the performance impacts.
>Because paragraph-level algorithms are slow, there are multiple variants to mitigate the performance impacts.[2]
The new draft[3] changed it to the current definition. What's also interesting from that new draft is this new note:
>The necessary computations may be expensive, especially when applied to large amounts of text. Authors are encouraged to assess the impact on performance when using text-wrap-style: pretty, and possibly use it selectively where it matters most.
which seems to go against what was written in the webkit blog. If developers start using this value everywhere expecting that it will be fast then that effectively stops future implementations from using a slower but better algorithm (assuming one exists).
[0] https://www.w3.org/TR/css-text-4/#propdef-text-wrap-style
[1] https://developer.chrome.com/blog/css-text-wrap-pretty
[2] https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...
[3] https://drafts.csswg.org/css-text-4/#text-wrap-style