The irony is that we've spent decades and quite some resources to perfect fixed text layout in general and text justification (the immaculate rectangle with homogenous gray values, hanging punctuation, all that jazz) in particular only to find:
1. Fixed layout isn't gonna cut it
2. Justification isn't that important anyways
And I say that coming from the typography nerd camp. No matter if we like it or not, in the end justified text has lost.
There is no mention of it in the post. If words (in any language) can be arbitrarily long and columns can be arbitrarily narrow, we will need to solve for this anyway.
Even without those extremes, I feel that there will always be place for the good old hypen when displaying or printing text for the main purpose of readability. No need to max out on perfect "look" in every application of text.
In fact in many places one might even find columns with jagged right edges more readable -- letting you visually distinguish each line from the one above/below it easily by length alone -- and may even lend a certain aesthetic character that is the opposite of mechanical / boring / machine produced / sterile.
Of course not negating the need for a well implemented method without bugs to justify text correctly when the use case demands it.
Hyphenation will probably lead to people thinking the content is generated by AI, which would be a significant downside for most websites. Users want to believe the site creator put effort in (regardless of whether they did or even if it's appropriate to have done.)
What is an example of a "high-end page-layout program" referenced in that document? I mean, of course I assume they exist for professional type setting, book publishing and such, but I have never seen or heard of the actual software.
We used Adobe InDesign at my last work, which I believe is an industry standard. Affinity Layout if you don’t want to sell your kidney to Adobe. Scribus is an open source project but I’m not sure how the quality is in that.
There is only Adobe InDesign. Even though you can make high quality layouts in other programs (Affinity, Scribus) once you get to actually printing in pro printer the whole pipeline is InDesign. It's Adobes secret money printer, software that many don't realize it rivals Photoshop in usage.
Thanks for that link! There is a bit more ... justification (pun intended) on that page for this recommendation to turn-on hypenation; and also some valuable advice on choosing spacing between words over spacing between letters.
I’m looking at the comparison [0] and the `pretty` example is hyphenated, while greedy is not. Not sure it’s fair to compare them like that, considering we’ve had `hyphens: auto` for a while now.
Edit: it’s actually vice versa! Which I should have known because the very next paragraph says:
> But the “smart” algorithm decides to add an entire line to it, which requires inflating all the white space proportionally.
Which is exactly how the example on the right looks.
That jumped out at me too... I'm not sure if they have different hyphenation properties set though, or if the greedy justified version just doesn't wind up hyphenating anywhere in this particular case?
Unfortunately there's no live HTML demo to inspect, just the images.
Playing around with it, seems that Safari simply stops hyphenating entirely when when text-wrap is pretty, regardless of whether it's justified or not. (If you smoothly resize the browser width, it makes it pretty easy to tell if hyphens ever come up.)
Which means the image on the left seems like it might be the wrong image?
And now I wonder if text-wrap: pretty is supposed to avoid hyphenation? Are hyphens not pretty? Or is it just a partial implementation by Apple, that they haven't gotten around to supporting hyphenation for it yet?
You can get it if you carefully adjust the window width! Or there’s one example in the author’s post – the word “implementation” is hyphenated for me [1].
So it looks like the algorithm tries to minimize hyphenation, which makes sense to be honest.
Ha. Oh wow. OK, I got "implementation" to hyphenate... but only once I changed the zoom level, and only for one specific exact window width. One pixel narrower or wider, and it stopped hyphenating.
So hyphenation exists in theory, but I'm just going to go ahead and say that however it's tuned seems completely broken.
Again, I think it’s very deliberate :-) Hyphenated words are slightly harder to read, so it makes sense to avoid them – maybe not as zealously, though.
> We are getting closer and closer to the cutting-edge XV-century technology. Beautiful paragraphs!
While the broader point is fine, the example to me is just bad to me: very narrow column with a lot of hyphens and identical width/no variety making it harder to anchor your eye (though colored letters are awesome and play this role)
Ok, bad rag is bad, but the ancient text goes overboard in the other direction. This looks close to the form-over-function vibe.
> Incipit epistola sancti iheronimi ad paulinum presbiterum de omnibus divine historie libris capitulum primum.
I'm not entirely up on all the abbreviations and and shorthand used in medieval manuscripts, but the macron over the final ū in 'capitulū' indicates the vowel being nasalized, which often happens before the final 'm' consonant which in this case is suspended. The 'pmū' is similar, but also I think a contraction or abbreviation for primum. With all these tricks available to the scribes it's no wonder they can make the right edge look nice.
I guess it’s safe to say that you can read Latin? What I’m trying to figure out is whether the typography in the Gutenberg Bible was exceptional for its time.
So I guess the fairer question may be whether Germans would’ve found Latin difficult to read in blackletter/Gothic type, which apparently descends from Roman cursive anyhow.
I asked my initial question (whether the grandparent commenter understood the language) because I wanted to figure out whether criticizing the typography as “form-over-function” made sense.
It's latin. "de omnibus" on the second line is pretty well recognizable. But holy hell is Gutenberg's font terrible. Look at the first word on the second line, it ends in seven undotted sticks that seem to bleed over into each other a bit. I read that as "mim" before I figured out it was "num".
Anyway, it's the Gutenberg bible. The epistle of St. Jerome, according to the alt text.
"While support for pretty shipped 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."
The article goes on to talk about how it's up to the browser (and not necessarily permanent) about how to handle the setting, and furthermore a new
value was agreed upon to do what Chromium was doing, called "text-wrap: avoid-short-last-lines".
Ah, OK. I finally got the demo to show a difference under one specific window width, where it changed the last line of a paragraph from one word to two words.
So it does exist... but yeah, barely does anything. Thank you for finding the explanation!
> Although Safari is the first browser to ship a non-joke implementation of text-wrap
(Emphasis mine.) Chrome is using a different algorithm for this, which probably fixes some typographic problems, but defaults to greed most of the time.
To be fair. It's not like the algorithms are not known and haven't been test implemented decades ago.
The issue has always been performance. When you have composer that considers paragraphs not just lines it can get slow very quickly. TeX is compiled it doesn't matter.
I can already see when browsers implement the TeX microtypography package, everyone starts using it and everyone will be annoyed how slow browsers, html and js are.
1. Fixed layout isn't gonna cut it
2. Justification isn't that important anyways
And I say that coming from the typography nerd camp. No matter if we like it or not, in the end justified text has lost.
There is no mention of it in the post. If words (in any language) can be arbitrarily long and columns can be arbitrarily narrow, we will need to solve for this anyway.
Even without those extremes, I feel that there will always be place for the good old hypen when displaying or printing text for the main purpose of readability. No need to max out on perfect "look" in every application of text.
In fact in many places one might even find columns with jagged right edges more readable -- letting you visually distinguish each line from the one above/below it easily by length alone -- and may even lend a certain aesthetic character that is the opposite of mechanical / boring / machine produced / sterile.
Of course not negating the need for a well implemented method without bugs to justify text correctly when the use case demands it.
Hyphenation will probably lead to people thinking the content is generated by AI, which would be a significant downside for most websites. Users want to believe the site creator put effort in (regardless of whether they did or even if it's appropriate to have done.)
https://practicaltypography.com/justified-text.html
[1]: http://www.nicemice.net/par/
Edit: it’s actually vice versa! Which I should have known because the very next paragraph says:
> But the “smart” algorithm decides to add an entire line to it, which requires inflating all the white space proportionally.
Which is exactly how the example on the right looks.
[0]: https://matklad.github.io/2026/02/14/justifying-text-wrap-pr...
Unfortunately there's no live HTML demo to inspect, just the images.
Playing around with it, seems that Safari simply stops hyphenating entirely when when text-wrap is pretty, regardless of whether it's justified or not. (If you smoothly resize the browser width, it makes it pretty easy to tell if hyphens ever come up.)
Which means the image on the left seems like it might be the wrong image?
And now I wonder if text-wrap: pretty is supposed to avoid hyphenation? Are hyphens not pretty? Or is it just a partial implementation by Apple, that they haven't gotten around to supporting hyphenation for it yet?
So it looks like the algorithm tries to minimize hyphenation, which makes sense to be honest.
[1]: https://matklad.github.io/2026/02/14/justifying-text-wrap-pr...
So hyphenation exists in theory, but I'm just going to go ahead and say that however it's tuned seems completely broken.
https://en.wikipedia.org/wiki/River_(typography)
While the broader point is fine, the example to me is just bad to me: very narrow column with a lot of hyphens and identical width/no variety making it harder to anchor your eye (though colored letters are awesome and play this role)
Ok, bad rag is bad, but the ancient text goes overboard in the other direction. This looks close to the form-over-function vibe.
> Incipit epistola sancti iheronimi ad paulinum presbiterum de omnibus divine historie libris capitulum primum.
I'm not entirely up on all the abbreviations and and shorthand used in medieval manuscripts, but the macron over the final ū in 'capitulū' indicates the vowel being nasalized, which often happens before the final 'm' consonant which in this case is suspended. The 'pmū' is similar, but also I think a contraction or abbreviation for primum. With all these tricks available to the scribes it's no wonder they can make the right edge look nice.
Veni vedi Gucci!
I guess it’s safe to say that you can read Latin? What I’m trying to figure out is whether the typography in the Gutenberg Bible was exceptional for its time.
So I guess the fairer question may be whether Germans would’ve found Latin difficult to read in blackletter/Gothic type, which apparently descends from Roman cursive anyhow.
I asked my initial question (whether the grandparent commenter understood the language) because I wanted to figure out whether criticizing the typography as “form-over-function” made sense.
Anyway, it's the Gutenberg bible. The epistle of St. Jerome, according to the alt text.
> WebKit devs, you are awesome for shipping this feature ahead of everyone else...
Um, no? Chrome shipped this feature in 2023: https://developer.chrome.com/blog/css-text-wrap-pretty
Safari isn't early shipping this, they're late. Though not as late as Firefox, admittedly.
In Safari, it’s a very different look.
Caniuse claims it's supported in Chrome: https://caniuse.com/mdn-css_properties_text-wrap_pretty
But you're right, it very clearly isn't working.
Is it a regression? Did it break and nobody noticed?
"While support for pretty shipped 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."
The article goes on to talk about how it's up to the browser (and not necessarily permanent) about how to handle the setting, and furthermore a new value was agreed upon to do what Chromium was doing, called "text-wrap: avoid-short-last-lines".
Here's the article on what the Chromium version does: https://developer.chrome.com/blog/css-text-wrap-pretty/
So it does exist... but yeah, barely does anything. Thank you for finding the explanation!
> Although Safari is the first browser to ship a non-joke implementation of text-wrap
(Emphasis mine.) Chrome is using a different algorithm for this, which probably fixes some typographic problems, but defaults to greed most of the time.
Edit: finally found it, see cousin comment.
One less gripe out html I guess. Still a few hundred left.
I can already see when browsers implement the TeX microtypography package, everyone starts using it and everyone will be annoyed how slow browsers, html and js are.