Better typography with text-wrap pretty

[taeric]

I find myself laughing at "Many developers are understandably concerned about the performance of text-wrap: pretty." I just can't bring myself to believe there is a meaningfully sized group of developers that have considered the performance of text-wrapping.

[queuebert]

Text wrapping is actually a difficult optimization problem. That's part of the reason LaTeX has such good text wrapping -- it can spend serious CPU cycles on the problem because it doesn't do it in real time.

[watersb]

The best study on the optimization of line breaking algorithms is now only on the Internet Archive. Lots of examples.

"Line Breaking", xxyxyz.org

https://web.archive.org/web/20171021044009/http://xxyxyz.org...

[_moof]

Same. I read that and think, oh NOW you all are worried about performance?

[zigzag312]

I once did a naive text wrapping implementation for a game and with a longer text it caused performance to drop way below 60 FPS.

This was on a 4.5 GHz quad core CPU. Single threaded performance of todays top CPUs is only 2-3x faster, but many gamers now have 144Hz+ displays.

[pcwalton]

Remember the days of Zuck saying "going with HTML5 instead of native was our biggest mistake"? Though hardware improvements have done a lot to reduce the perceptible performance gap between native and the Web, browser developers haven't forgotten those days, and layout is often high in the profile.

[jcelerier]

I have to consider the performance of rendering text literally all time, even without wrapping. This is one of the most gluttonous operations when rendering a UI if you want, say, 60 fps on a raspberry pi zero.

[dominicrose]

Basically everything that comes built-in a browser has to be perform well in most use-cases and most devices. We don't want an extra 5% quality at the cost of degraded performance.

[0cf8612b2e1e]

Open any random site without an ad blocker and it is clear that nobody cares about well optimized sites.

[alwillis]

I just can't bring myself to believe there is a meaningfully sized group of developers that have considered the performance of text-wrapping.

You're kidding, right? There are a ton of non-trivial edge cases that have to be considered: break points, hyphenation, other Latin-based languages, etc.

From a Google engineer's paper describing the challenges: https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...

    Performance Considerations
    While the `text-wrap: pretty` property is an opt-in to accept slower
    line breaking, it shouldn’t be too slow, or web developers can’t use
     them due to their performance restrictions.
    
    The pinpoint result when it is enabled for all web_tests is in this CL.
    Complexity
    The score-based algorithm has different characteristics from the
    bisection algorithm. The bisection algorithm is O(n * log w) where n is
    the number of lines and w is the sum of spaces at the right end. The
    score-based algorithm is O(n! + n) where n is the number of break
    opportunities, so it will be slower if there are many break
     opportunities, such as when hyphenation is enabled.
    
    Also, computing break opportunities are not cheap; it was one of
    LayoutNG's optimizations to minimize the number of computing break
     opportunities. The score-based algorithm will lose the benefit.

    Last 4 Lines
    Because computing all break opportunities is expensive, and computing
    the score is O(n!) for the number of break opportunities, the number of
    break opportunities is critical for the performance. To minimize the
    performance impact, the implementation caches 4 lines ahead of the
     layout.
    Before laying out a line, compute line breaking of 4 lines ahead of the
     layout.
    If it finds the end of the block or a forced break, compute the score
     and optimize line breaks.
    Otherwise layout the first line from the greedy line breaking results,
     and repeat this for the next line.
    The line breaking results are cached, and used if the optimizer decided
     not to apply, to minimize the performance impact.
    
    Currently, it applies to the last 4 lines of each paragraph, where
    “paragraph” is content in an inline formatting context separated by
     forced breaks.
    The Length of the Last Line
    Because the benefit of the score-based line breaking is most visible
    when the last line of the paragraph is short, a performance
    optimization is to kick the optimizer in only when the last line is
     shorter than a ratio of the available width.
        
    Currently, it applies only when the last line is equal to or less than ⅓
    of the available width.
    Checking if the last line has only a single word
    Checking if the last line has only a single word (i.e. no break
     opportunities) requires running the break iterator, but only once.

[mdhb]

I think this is the kind of nonsense the Safari team tells themselves so that they can continue to ship absolutely fucking nonsense features like this while ignoring anything that encroaches on the idea of the web becoming a meaningful competitor to their walled garden where they are able to rip off every single person involved every time a transaction occurs.

[tiltowait]

I’m pretty excited for this to be added to ereaders, which notoriously (among people who care about this kind of thing) have terrible layout engines.

[velcrovan]

Better ways of laying out digital text have existed since before ereaders existed. Even this one CSS directive has already been supported by Chrome for two years. What's missing is Amazon & co. giving a shit about it. That needle shows no signs of moving.

[TiredOfLife]

Currently on Android i use Moon+ reader that has hyphenation + hanging punctuation. Before that (2008-2013) I used eInk reader that came with CoolReader (its layout engine "crengine" is the base for KOReader) that also had good hyphenation and hanging punctuation and nice footnotes.

So in my experience ereaders have had great layout engines.

[Finnucane]

Given the way ebook software is developed, it'll be years before this makes it to a device near you.

[MBCook]

Note that it’s up to the browser to do whatever it thinks is best. They didn’t lay down specific rules.

So unless the e-reader uses an engine that already has good rules there will be no real change unless the manufacturer does what it should have already.

[taeric]

Is this where folks will get it for ereaders? Naively, I hadn't realized ereaders were glorified webkit displays.

[spookie]

Sometimes I like to think Knuth may have intrusive violent thoughts about how shit programmers make text look.

[numbers]

yeah, I agree, sometimes reading an ebook feels very off b/c of the lines just looking way too justified

[Sloppy]

Far to little effort and attention has been devoted to creating beautiful text online. The web set text back centuries. In some ways it was never this bad except for the monospaced typewriters. This is welcome indeed.

[accrual]

This made me think of one person who cares for it - Matthew Butterick's Practical Typography appears to have spent quite a bit on bringing typeset-like text to his website.

https://practicaltypography.com/

[crazygringo]

This is fantastic. I'm not surprised they focus on short last lines and on rag, since it's easy to imagine defining metrics for them to then minimize.

But they say:

> We are not yet making adjustments to prevent rivers, although we’d love to in the future.

And indeed, I couldn't even begin to guess how to define a metric for rivers, that can occur at different angles, with different variation, being interrupted by various degrees... I'm curious if there's a clever metric anybody has invented that actually works? Or does it basically require some level of neural-network pattern recognition that is way too expensive to calculate 1,000 variations of for each paragraph?

[ameliaquining]

There's a TeX package that, among many other features, detects rivers: https://mirrors.ibiblio.org/pub/mirrors/CTAN/macros/latex/co...

The intent here is that the document author is informed that their text contains rivers, and responds by tweaking the wording until they land on something that doesn't have them.

Of course, for a browser engine this is a complete nonstarter; a useful feature for dealing with rivers would require not just detecting them but automatically removing them, without changing the text content. I'm not aware of any existing software that does this, but I've found one proposed list of exploratory directions that could make a decent starting point for anyone who wanted to build this: https://tex.stackexchange.com/a/736578

[taeric]

I think the main difficulty is that it is a paragraph level optimization and not a line one. Right? Otherwise, it seems like you can probably get pretty far by defining a metric that looks at connected whitespace sections between lines? With higher penalty for connected space between words that has been stretched. (That is, if you have space between some words expanded to make them pretty at the edge, those will be more visible as rivers if they are stacked?)

And, yes, there are some concerns that are done at the line level that could lead to a paragraph getting reworked. Ending with a single word, is an easy example. That is still something where you can evaluate it at the line level easily.

[6510]

I hve no idea but it looks something like this

https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122...

[fngjdflmdflg]

>The purpose of pretty, as designed by the CSS Working Group, is for each browser to do what it can to improve how text wraps. [...] There is no mandate for every browser to make the same choices. In fact, a browser team might decide in 2025 to handle some aspects of improving these qualities, and then change what their implementation does in the future. [...] Because of the way Chrome’s implementation of pretty has been taught, a lot of web developers expect this value is only supposed to prevent short last lines. But that was never the intention.

Why did they even design it like this in the first place? This seems like it is counter to much of what browsers have been doing recently like being able to customize select, the browser interop and baseline projects, web platform test etc. I would rather move away from these types of features in favor of more explicit ones. I understand that this isn't a serious issue and is unlikely to cause bugs compared to other interop issues which are true deviations from the spec. It just seems counterintuitive to do this though.

[giraffe_lady]

They point to the reason in the intro but don't make it explicit: it's because this is at the intersection of computing with a much older tradition, typesetting.

There's no "correct" way to typeset a document, there wouldn't even be a consensus among typesetters on what the implementation specifics look like. Rather than turn the spec committee into a decades-long ecumenical council of typographers they just left the specifics up to each individual "shop" as it always has been. Except now instead of printers it's the browser vendors needing to make the final call.

[moralestapia]

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.

[mac3n]

> The demo has content in English

strange English.

> It's far text

> this text has short a lot of words all in a row

not relevant to the subject, unless you want to consider improving line breaks by rearranging words

[throw0101d]

(La)Tex still seems to have the 'best' results for line breaking:

* https://en.wikipedia.org/wiki/Knuth–Plass_line-breaking_algo...

[robszumski]

Really excited for text-wrap: balance. This will prevent a ton of breakpointing or manual line breaks for web headers.

[qingcharles]

balance has been working for a couple of years on everything except Safari (about a year on that I think). I've been using it on my headlines for that long.

[IshKebab]

Ironically the letter height for the monospace text on this website is all over the place for me. I'm using Chrome on Windows so you'd think it would work fine... Seems to be an issue with SF Mono.

[janalsncm]

I’d love to learn more about the pretty algorithm and the optimizations that have been tried out so far.

It seems like a pretty straightforward machine learning regression problem: given a sequence of word widths, find a line length which when applied to the sequence satisfy the constraint of being “pretty”.

Using a model would allow computing the answer in constant time.

[OisinMoran]

This is excellent, thank you! I hadn't heard of "balance" before either, so definitely going to experiment with that now too. Anything that can improve typography on the web, even a little bit is a big win in my opinion. I'm also stealing that 1lh tip they link to!

If you like this and are interested in something closer to TeX, why not the TeX algorithm itself!? There's this lovely package that works wonderfully on the web https://github.com/robertknight/tex-linebreak?tab=readme-ov-... And if you want to play around with a live example to check the performance, I use it on my site's about page: https://lynkmi.com/about

Been on a big LaTeX buzz recently and even added support for it in comments there too!

[rambambram]

After a quick glance this looks pretty useful for me. I'm the kind of guy who is willing to change words or sentences (up to a point) to make the overall text look prettier.

[aktau]

Does anyone know how this contrasts with `text-align: justify` (mentioned in https://news.ycombinator.com/item?id=43258709#43260606)?

In Chrome (can't test Safari), `text-wrap: pretty` has a much milder effect.

Should one use both together in the main text of your average blog? I checked, they do appear to make individual changes.

[DadBase]

I’ve been doing this manually for years using non-breaking spaces and zero-width joins. Glad WebKit is finally catching up.

[donbrae]

This is great. I’ve already been using `text-wrap: balance` on headlines. Before, I was concatenating certain words with ` ` to try to avoid bad wrapping at certain viewport widths. (Doing so is still a useful trick in edge cases.) `text-wrap: pretty` should fix similar ugliness in body text.

[intelliot]

Is there any concrete data showing whether this has any effect on the readability or comprehensibility of text content?

[david2ndaccount]

This does actually look a lot better. Using the inspector to toggle it on and off, “pretty” does look a lot prettier.

[pronik]

> Support for text-wrap: pretty just shipped in Safari Technology Preview, bringing an unprecedented level of polish to typography on the web.

According to caniuse.com, Chrome has had support for this since September 2023. Maybe I'm dumb, but what's so "unprecedented" about this?

[lloeki]

in TFA, it is explained how Chromium only considers the last four lines and aims to only solve one aspect (lone word) and none of rivers, bag rags, hyphenation, etc...

Comparatively:

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

[marcellus23]

You're not dumb but you didn't read the article.

[dspillett]

This is how the Apple world works. Things go from unnecessary to revolutionary at the point Apply implements them, no matter how long other implementations might have already existed.

[executesorder66]

I'm confused, this was created by Webkit, but is currently only available on Chromium based browsers according to : https://caniuse.com/?search=text-wrap%20pretty

How did that happen?

[ameliaquining]

text-wrap: pretty tells the browser to wrap the text so as to make it look pretty. But the CSS standard doesn't specify what exactly that means; it's up to each individual browser to decide what algorithm yields the prettiest results.

Chromium is the only browser engine whose stable channel currently supports text-wrap: pretty. In this post, WebKit is announcing not only that they've implemented it (though not yet in a stable channel), but that they've done so using an algorithm that's better than Chromium's. Their algorithm adjusts for various things that Chromium's currently does not.

[velcrovan]

It wasn't created by WebKit. WebKit is announcing (at last) support for it.

[moogleii]

https://news.ycombinator.com/item?id=43630964

[wruza]

As we reached such thin matters, can we have now "ui: modular" and "data-changes: async autoupdate"? Cause using a tight userland framework for components and [a]syncing data to ui starts getting a little old.