4 ms·
> Inexplicably, until 2025, browsers stuck with the naive greedy algorithm, subjecting generations of web users to ugly typography. > WebKit devs, you are awes
by nayroclade 8mo ago
> Inexplicably, until 2025, browsers stuck with the naive greedy algorithm, subjecting generations of web users to ugly typography.
> 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 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.
- notpushkin 8mo agoHmm, I’m looking at the demo in Chrome and don’t see any difference when I turn on `pretty`: https://cdpn.io/pen/debug/xxvoqNM https://cdpn.io/pen/debug/xxvoqNM In Safari, it’s a very different look.
- crazygringo 8mo agoYeah, very weird. Caniuse claims it's supported in Chrome: https://caniuse.com/mdn-css_properties_text-wrap_pretty 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?
- notpushkin 8mo agoI think the answer is in the post: > 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.
- crazygringo 8mo agoInteresting. As far as I can tell, Chrome isn't doing anything different. I can't find any window width where the checkbox makes any difference. Edit: finally found it, see cousin comment.
- no_news_is 8mo agoFrom https://webkit.org/blog/16547/better-typography-with-text-wrap-pretty/ https://webkit.org/blog/16547/better-typography-with-text-wr... "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/ https://developer.chrome.com/blog/css-text-wrap-pretty/
- notpushkin 8mo agoAmazing summary. Thank you so much!
- crazygringo 8mo agoAh, 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!
- noosphr 8mo agoSo only 42 years after TeX instead of 44. One less gripe out html I guess. Still a few hundred left.
- omnimus 8mo agoTo 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.
- tosti 8mo agoThat's already the case thanks to a billion JS extensions and frameworks.