While this is valuable work, leaving it implementation-dependent is a terrible mistake.
The whole point of CSS is/was to standardize presentation across browsers.
The whole point of CSS is/was to standardize presentation across browsers.
CSS was created to standardize how to deal with presentation, but that doesn't mean every website should look exactly the same on every device or in every browser. The era of attempting to do that is over.
text-wrap: pretty is a great example of progressive enhancement [1]: it's a great way to add some polish to a website but if the user's device doesn't support it, they can still access all of the content on the site and be none the wiser.
If you read the CSS specifications, browser makers, in some cases, are allowed to use platform-specific heuristics to determine whether or not to execute certain features. Downloading web fonts works like this—browsers fallback to system fonts if a webfont doesn't download within 3 seconds.
It makes sense that text-wrap: pretty should be one of those. If your smartphone is low on power and the signal isn't that great, you can forgo expertly wrapped text and elegant hyphenation in order to view the webpage as quickly as possible.
>CSS was created to standardize how to deal with presentation, but that doesn't mean every website should look exactly the same on every device or in every browser. The era of attempting to do that is over.
For every device I agree but that was never the goal of CSS. It is meant to respond to the device's constraints such as screen dimensions and device type (desktop, mobile, print) using eg. media queries. In every browser I do think they should try to accomplish the same thing. Even if the exact algorithms used are different, the intended result should be agreed upon.
>but that doesn't mean every website should look exactly the same on every device or in every browser
That was the point. Maybe Gen Z changed its meaning now, but that was the main premise. There was even the Acid3 test and similar stuff.
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).
[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...