[HN Gopher] Better typography with text-wrap pretty
___________________________________________________________________
Better typography with text-wrap pretty
Author : todsacerdoti
Score : 135 points
Date : 2025-04-08 15:10 UTC (7 hours ago)
(HTM) web link (webkit.org)
(TXT) w3m dump (webkit.org)
| tiltowait wrote:
| 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.
| numbers wrote:
| yeah, I agree, sometimes reading an ebook feels very off b/c of
| the lines just looking way too justified
| MBCook wrote:
| 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.
| spookie wrote:
| Sometimes I like to think Knuth may have intrusive violent
| thoughts about how shit programmers make text look.
| TiredOfLife wrote:
| 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 wrote:
| Given the way ebook software is developed, it'll be years
| before this makes it to a device near you.
| velcrovan wrote:
| 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.
| Cthulhu_ wrote:
| I was about to ask about that, how are / were traditional
| paper books lined out to prevent this? Surely not by hand.
| Proprietary software maybe?
| Sharlin wrote:
| Well, before desktop publishing, by phototypesetting [1],
| before that by hot-metal typesetting [2], before that, by
| hand. Nowadays, with software like Adobe InDesign, of if
| you happen to be a CS/math/physics nerd, with LaTeX, which
| has a famously high-quality layouting engine that utilizes
| the Knuth-Plass line-breaking algorithm [3]. Indeed it's
| fairly well known that Donald Knuth _created TeX_ because
| he wasn 't happy with the phototypeset proofs he received
| in 1977 for the second edition of _The Art of Computer
| Programming_ , finding them inferior compared to the hot-
| metal typeset first edition.
|
| [1] https://en.wikipedia.org/wiki/Phototypesetting
|
| [2] https://en.wikipedia.org/wiki/Hot_metal_typesetting
|
| [3] https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-
| break...
| aardvark179 wrote:
| Books were produced before computers, and with very good
| typesetting. One difference between websites and books is
| that theee is a feedback loop with books where somebody ia
| at looking at the layout and either adjusting the spacing
| subtly, or even editing the text to avoid problems.
| Sometimes this is just to ensure that left justified text
| isn't too ragged on the right edge, sometimes it's to avoid
| river of space rubbing through a paragraph, and sometimes
| it's editing or typesetting to avoid orphans.
|
| But text on a page is set for a set layout, and that's
| where the web really differs.
| Telemakhos wrote:
| The old linotype machines had visual indicators of minimum
| and maximum line width, and the operator would make a
| judgement call with each line. Spacers would then
| automatically justify the letters. It was all mechanical
| and amazing.
|
| See http://widespacer.blogspot.com/2014/01/two-spaces-old-
| typist... for many details.
| MBCook wrote:
| > Even this one CSS directive has already been supported by
| Chrome for two years
|
| The article says what chrome does is only support the "no
| super short lines" bit.
|
| So while you won't end up with one word on its own line at
| the end of a paragraph, it's not trying to prevent rivers of
| text or keep a relatively clean ragged right or anything
| else.
|
| That's allowed by spec, but it's not quite the same thing.
| taeric wrote:
| Is this where folks will get it for ereaders? Naively, I hadn't
| realized ereaders were glorified webkit displays.
| mintplant wrote:
| EPUB is HTML.
|
| https://www.w3.org/TR/epub-33/
| taeric wrote:
| I knew it was related, but I had assumed it did not rely on
| CSS. Again, I noted it was a naive view.
|
| Granted, I probably view CSS with far more disdain than I
| should.
| NetOpWibby wrote:
| CSS is your friend
| Eddy_Viscosity2 wrote:
| Anybody know what font the article uses? I like it.
| jsheard wrote:
| The sans is Apple's own SF Pro, and the code is SF Mono.
| jasonjmcghee wrote:
| For next time, just right-click the text you're trying to
| identify the font for, hit "Inspect" and click "Computed" on
| the right in the styles sidebar. And you'll see `font-family`.
|
| You'll often see multiple listed, like `-apple-system, "SF Pro
| Text", Helvetica, sans-serif` in this case. It tries to use
| them from left to right.
| sim04ful wrote:
| It uses: SF Display, SF Mono, and SF Text, designed by Apple.
|
| In case you come across other website fonts you like, you can
| use https://fontofweb.com to get their names.
|
| Disclaimer: I'm the creator
| rambambram wrote:
| 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.
| executesorder66 wrote:
| 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?
| velcrovan wrote:
| It wasn't created by WebKit. WebKit is announcing (at last)
| support for it.
| executesorder66 wrote:
| Now it makes much more sense.
|
| I realize I misread "One solution is text-wrap:pretty" as
| "OUr solution is text-wrap:pretty". Combined with the fact
| that this was on the webkit blog.
|
| Thanks.
| ameliaquining wrote:
| 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.
| robszumski wrote:
| Really excited for text-wrap: balance. This will prevent a ton of
| breakpointing or manual line breaks for web headers.
| crazygringo wrote:
| 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?
| 6510 wrote:
| I hve no idea but it looks something like this
|
| https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122...
| ameliaquining wrote:
| 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 wrote:
| 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.
| crazygringo wrote:
| I think the difficulties are, how close do spaces need to be
| to be considered connected? Rivers aren't only perfectly
| vertical. And to what degree do they need to maintain the
| same angle across consecutive lines? How much can they
| wiggle? And a river is still visible across 10 lines even if
| one line in the middle doesn't have the space, so it needs to
| be able to handle breaks in contiguity.
|
| There's no problem with paragraph-level optimizations
| inherently. Reducing raggedness is paragraph-level and that's
| comparatively easy. The problem is the metric in the first
| place.
| taeric wrote:
| I wouldn't try and consider spaces individually, I don't
| think? Rather, I'd consider the amount of space being
| considered. We aren't talking about fixed width
| typesetting, after all. To that end, you will have more
| space after punctuation and such. Rather than try to
| enumerate the different options, though, you almost
| certainly have some model of how much "space" is in a
| section. Try different model weights for how much to
| penalize different amounts of connected space and see how
| well different models optimize.
|
| Or, maybe not? I'll note that the vast majority of "rivers"
| I've seen in texts coincide with punctuation quite heavily.
| Even the example in this article has 5/8 lines using a
| comma to show the river. With the other lines having what
| seems to be obvious stretched space between words to use
| more of the line? Maybe enumerating the different reasons
| for space would be enough?
|
| Granted, this also calls out how dependent you almost
| certainly are on the font being used, as well?
| pradn wrote:
| I see a good number of these articles, each with their own
| typographic features. Is there a "gold standard" set of
| recommendations for making the most beautiful type, on the web?
| presbyterian wrote:
| I know a lot of people will point you to Practical Typography.
| I reference it a lot myself, and even though I don't agree with
| everything there, it's a really, really great reference and
| gets you thinking about the goals of your typography.
|
| https://practicaltypography.com/
| throw0101d wrote:
| (La)Tex still seems to have the 'best' results for line breaking:
|
| * https://en.wikipedia.org/wiki/Knuth-Plass_line-breaking_algo...
| david2ndaccount wrote:
| This does actually look a lot better. Using the inspector to
| toggle it on and off, "pretty" does look a lot prettier.
| IshKebab wrote:
| 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.
| taeric wrote:
| 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 wrote:
| 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.
| jkmcf wrote:
| That's true, but I think the OP is commenting on the state of
| FE development :)
| taeric wrote:
| Largely, yes. I also challenge if it would be measurable
| for the size of most sites.
|
| Typesetting all of wikipedia? Probably measurable.
| Typesetting a single article of wikipedia? Probably not.
| And I'd wager most sites would be even easier than
| wikipedia.
| taeric wrote:
| You aren't wrong; but I stand by my claim. For one, plenty of
| things are actually difficult optimization problems that
| people don't give any passing thought to.
|
| But, more importantly, the amount of cycles that would be
| needed to text-wrap most websites is effectively zero. Most
| websites are simply not typesetting the volumes of text that
| would be needed for this to be a concern.
|
| Happy to be shown I'm flat wrong on that. What sites are you
| envisioning this will take a lot of time for?
| NoMoreNicksLeft wrote:
| Won't this end up in Apple iBooks or whatever it's called
| now? Most novels can be a megabyte or more of text, pretty
| much all of it needing to be wrapped.
| CharlesW wrote:
| It seems more likely that Apple would've adapted this
| from the proven technology that they currently use for
| Apple Books and everything else, TextKit (which first
| appeared in OpenStep).
| https://developer.apple.com/videos/play/wwdc2021/10061/
| taeric wrote:
| I mean, not wrong. But optimizing over a megabyte's worth
| of text is almost certainly not going to take a lot of
| time. Especially as there will be chapter stops. Such
| that we are down to, what 100k of text per chapter to
| layout?
|
| Again, I won't claim it is absolutely free. It is almost
| certainly negligible in terms of processing power
| involved with any of the things we are talking about.
| binaryturtle wrote:
| With the current state of Websites and how much resources
| they waste any text wrapping is probably not an issue at
| all. :)
|
| I hardly can open any website w/o some anti-bot check
| burning my CPU to the ground for 1/2 minute or something
| (if it doesn't manage to entirely crash my Firefox in the
| process like cloudflare). I rather would wait for 0.2s text
| wrapping than that, that's for sure. :)
| cobertos wrote:
| Any page with dynamic text. If the calculation takes a
| moderate amount of time, that will accumulate if the page
| layout reflows a lot.
| taeric wrote:
| Only if the entire text has to be optimized as a whole?
| Which, most dynamic text sites do not have to do this.
| Most dynamic sites will be a series of individual "card"
| like things that could be justified internally, but are
| not justified with regard to anything else on the page.
| contact9879 wrote:
| Quick example would be
| https://standardebooks.org/ebooks/mark-twain/the-
| innocents-a...
|
| Try zooming in and out with text-wrap: pretty vs text-wrap:
| wrap
| taeric wrote:
| I... uh, wouldn't consider a text dump of a full novel
| getting completely typeset as a good example to consider
| when talking about sites?
| contact9879 wrote:
| sure, but html isn't only used in a browser context. I
| have a severely under-powered ereader that I use to read
| epubs (html). It already takes ten seconds to paginate on
| first open and font size changes. I can't imagine how
| long it would take to non-naively wrap lines
| taeric wrote:
| I don't know why you'd expect an ereader to do a full
| text optimization of a book, though? Pick the starting
| line and layout to the next screen's breaking point. If
| needed, consider if you left an orphan for the next page
| and try to adjust that into the current screen.
|
| Are there ereaders that have to typeset the entire text
| of what you are reading? What is the advantage of making
| the task harder?
| int_19h wrote:
| Lest we forget, TeX is almost 50 years old now, so what
| constitutes "serious CPU cycles" has to be understood in the
| context of hardware available at the time.
| porphyra wrote:
| But with modern hardware, running the dynamic programming
| solution to this optimization problem takes a trivial amount
| of cycles* compared to rendering your typical React webapp.
|
| * for most webpages. Of course you can come up with giant
| ebooks or other lengthy content for which this will be more
| challenging.
| 0cf8612b2e1e wrote:
| Open any random site without an ad blocker and it is clear that
| nobody cares about well optimized sites.
| lcnPylGDnU4H9OF wrote:
| The developer in such a case is only allowed to care as much
| as the PM.
| _moof wrote:
| Same. I read that and think, oh NOW you all are worried about
| performance?
| fngjdflmdflg wrote:
| >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 wrote:
| 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.
| fngjdflmdflg wrote:
| >There's no "correct" way to typeset a document
|
| They can add multiple typesetting properties and allow the
| develop to decide which one to use. Besides, letting each
| browser decide what the "best" line break looks like doesn't
| solve the problem of there not being a definitive answer to
| that question. Even here, I don't think the Chrome developers
| have a vastly different opinion on what a good line break
| looks like. It's possible they didn't like the performance
| implications of webkit's version or had some other tangential
| reason, although the blog says performance is not an issue.
| giraffe_lady wrote:
| ok. you should tell them.
| Sloppy wrote:
| 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.
| intelliot wrote:
| Is there any concrete data showing whether this has any effect on
| the readability or comprehensibility of text content?
| tobr wrote:
| Good question, but keep in mind that it's claiming to `text-
| wrap: pretty`, not `text-wrap: comprehensible`. That should be
| enough!
| DadBase wrote:
| I've been doing this manually for years using non-breaking spaces
| and zero-width joins. Glad WebKit is finally catching up.
| OisinMoran wrote:
| This is excellent, thank you! I hadn't heard of "balanced" 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!
___________________________________________________________________
(page generated 2025-04-08 23:00 UTC)