CSS “text-wrap: pretty” in WebKit
Support for
text-wrap: prettyjust shipped in Safari Technology Preview, bringing an unprecedented level of polish to typography on the web.[…]
Now, the web has the ability to evaluate the whole passage of text when figuring out where best to wrap. You can ask browsers to do this by using
text-wrap: pretty. WebKit is not the first browser engine to implement, but we are the first browser to use it to evaluate and adjust the entire paragraph. And we are the first browser to use it to improve rag. We chose to take a more comprehensive approach in our implementation because we want you to be able to use this CSS to make your text easier to read and softer on the eyes, to provide your users with better readability and accessibility.[…]
While support for
prettyshipped in Chrome 117, Edge 177, and Opera 103 in Fall 2023, and Samsung Internet 24 in 2024, the Chromium version is more limited in what it accomplishes. According to an article by the Chrome team, Chromium only makes adjustments to the last four lines of a paragraph. It’s focused on preventing short last lines. It also adjusts hyphenation if consecutive hyphenated lines appear at the end of a paragraph.[…]
Perf concerns emerge as the
prettyalgorithm takes more and more lines into consideration as it calculates what to do. In WebKit-based browsers or apps, your text element would need to be many hundreds or thousands of lines long to see a performance hit — and that kind of content is unusual on the web. If your content is broken up into typical-length paragraphs, then you have no reason to worry.[…]
Basically, the
text-wrap: balancerule tells the browser to wrap in such places to make every line be about the same length as the others. I think of it like folding a piece of paper into halves, or thirds, or quarters.
Stephanie Stimac (via ktguru):
With
text-wrap: balance;, because there’s a limit to how many lines the browser will wrap, this should only be used on headlines, headings, and subheadings. Applying it to large paragraphs will have no effect and comes at a performance cost because the browser is trying to calculate optimal balance even though it won’t apply anything.
I have mixed feelings about the results. Here are saved PDFs showing the rendering of my “How Many New iPhones Can Fit on a Freight Plane?” article from earlier today: first with traditional
text-wrap: autoline wrapping, and second with WebKit’s newtext-wrap: prettyin STP 216. Looking at each paragraph by itself, there’s no question this new layout algorithm is, well, prettier. The problem I see is going from one paragraph to another. Within a paragraph, WebKit’s newprettywrapping definitely makes lines a more uniform width. But in some cases it so narrows an entire paragraph that it makes going from one paragraph to the next jarring. Line-to-line the new algorithm looks better, but paragraph-to-paragraph I think it looks worse.
2 Comments RSS · Twitter · Mastodon
I wonder how is it that SwiftUI does not offer anything like this - the native app loses here (for content where this might make sense)
That Gruber example is devastating. How did they not think of this when designing this feature? There must be a way to define a parent relative to which all child paragraphs are formatted.
