6 ms·

Better typography with text-wrap pretty

364 points by todsacerdoti 2y ago

rambambram 2y ago
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.
- wruza 2y ago
  I also do this for monospace text, but in proportional there's perfect "fill" justification which for some reason gets ignored. Here's how you do it in advanced layout systems like CSS: https://stackoverflow.com/questions/6205109/justify-text-to-fill-a-div https://stackoverflow.com/questions/6205109/justify-text-to-...
tiltowait 2y ago
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 2y ago
  yeah, I agree, sometimes reading an ebook feels very off b/c of the lines just looking way too justified
- MBCook 2y ago
  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 2y ago
  Sometimes I like to think Knuth may have intrusive violent thoughts about how shit programmers make text look.
  - deleted 2y ago
    [deleted]
- TiredOfLife 2y ago
  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 2y ago
  Given the way ebook software is developed, it'll be years before this makes it to a device near you.
  - archagon 2y ago
    I dunno, I imagine Apple Books would be eager to implement this as soon as possible.
- velcrovan 2y ago
  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_ 2y ago
    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 2y ago
      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 https://en.wikipedia.org/wiki/Phototypesetting [2] https://en.wikipedia.org/wiki/Hot_metal_typesetting https://en.wikipedia.org/wiki/Hot_metal_typesetting [3] https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-breaking_algorithm https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-break...
    - aardvark179 2y ago
      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.
    - 2y ago
- taeric 2y ago
  Is this where folks will get it for ereaders? Naively, I hadn't realized ereaders were glorified webkit displays.
  - mintplant 2y ago
    EPUB is HTML. https://www.w3.org/TR/epub-33/ https://www.w3.org/TR/epub-33/
    - taeric 2y ago
      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 2y ago
        CSS is your friend
        taeric 2y ago
        The cascading aspect is mostly a big L. As is the dream of user style sheets. All the more so from the obfuscated style names so many tools saddle us with. Don't get me wrong, there are smart people working on css. That we decided, as an industry, to treat layout as a Rube Goldberg machination of interacting rules on a growing number of elements is not something you can easily overcome.
Eddy_Viscosity2 2y ago
Anybody know what font the article uses? I like it.
- jsheard 2y ago
  The sans is Apple's own SF Pro, and the code is SF Mono.
- jasonjmcghee 2y ago
  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.
  - deleted 2y ago
    [deleted]
  - ygra 2y ago
    Browsers typically say below the styles also which fonts are actually used (there can be multiple, e.g. when substitution is required to render certain characters).
- sim04ful 2y ago
  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 https://fontofweb.com to get their names. Disclaimer: I'm the creator
executesorder66 2y ago
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 https://caniuse.com/?search=text-wrap%20pretty How did that happen?
- velcrovan 2y ago
  It wasn't created by WebKit. WebKit is announcing (at last) support for it.
  - executesorder66 2y ago
    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.
  - alwillis 2y ago
    The WebKit implementation is the only one that can handle many pages of text with no noticeable performance hit, while Chrome and Firefox are limited to only dealing with the last 4 or 6 lines of a paragraph.
    - TiredOfLife 2y ago
      Firefox doesn't have this feature at all.
      - mrandish 2y ago
        I was curious as it seems like a nice thing to have and I use Firefox, so I looked it up. It's been suggested and you can upvote it here: https://connect.mozilla.org/t5/ideas/text-wrap-pretty-for-desktop-mobile/idi-p/63133 https://connect.mozilla.org/t5/ideas/text-wrap-pretty-for-de.... Per the last post there (Aug 24). > Mozilla standard position on this feature is positive > https://github.com/mozilla/standards-positions/issues/993 https://github.com/mozilla/standards-positions/issues/993
robszumski 2y ago
Really excited for text-wrap: balance. This will prevent a ton of breakpointing or manual line breaks for web headers.
- qingcharles 2y ago
  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.
crazygringo 2y ago
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 2y ago
  I hve no idea but it looks something like this https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122,0.004,1.106,0.419,0 https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122...
- ameliaquining 2y ago
  There's a TeX package that, among many other features, detects rivers: https://mirrors.ibiblio.org/pub/mirrors/CTAN/macros/latex/contrib/impnattypo/impnattypo.pdf 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 https://tex.stackexchange.com/a/736578
- taeric 2y ago
  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.
pradn 2y ago
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 2y ago
  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/ https://practicaltypography.com/
throw0101d 2y ago
(La)Tex still seems to have the 'best' results for line breaking: * https://en.wikipedia.org/wiki/Knuth–Plass_line-breaking_algorithm https://en.wikipedia.org/wiki/Knuth–Plass_line-breaking_algo...
david2ndaccount 2y ago
This does actually look a lot better. Using the inspector to toggle it on and off, “pretty” does look a lot prettier.
IshKebab 2y ago
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 2y ago
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 2y ago
  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 2y ago
    That's true, but I think the OP is commenting on the state of FE development :)
    - taeric 2y ago
      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 2y ago
    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 2y ago
      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.
fngjdflmdflg 2y ago
>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 2y ago
  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 2y ago
    >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.
Sloppy 2y ago
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 2y ago
  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/ https://practicaltypography.com/
  - ashton314 2y ago
    MB over-engineered that book. Example: look at the paragraph that stars “But I don’t have visual skills” on this page: https://practicaltypography.com/why-does-typography-matter.html https://practicaltypography.com/why-does-typography-matter.h... Notice how the open quotation marks hang into the left margin. There’s been some recent work with CSS to make this automatic, but that’s newer than this book and support is spotty. MB made it happen with a (iirc) custom filter inside the Pollen setup he made for this book. Wild. And beautiful.
    - flobosg 2y ago
      See also the added soft hyphens within each word for hyphenation: https://practicaltypography.com/optional-hyphens.html#:~:text=For%20the%20hy%C2%ADphen%C2%ADation%20in%20this%20book https://practicaltypography.com/optional-hyphens.html#:~:tex...
      - OisinMoran 2y ago
        Ironically (or not) this section (on mobile anyway) seems to hyphenate way too much, with three lines in a row and two lines in a row ending in a hyphen (5/8 total lines in the paragraph).
intelliot 2y ago
Is there any concrete data showing whether this has any effect on the readability or comprehensibility of text content?
- tobr 2y ago
  Good question, but keep in mind that it's claiming to `text-wrap: pretty`, not `text-wrap: comprehensible`. That should be enough!
  - eviks 2y ago
    It's claiming both: > 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.
DadBase 2y ago
I’ve been doing this manually for years using non-breaking spaces and zero-width joins. Glad WebKit is finally catching up.
OisinMoran 2y ago
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-file 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 https://lynkmi.com/about Been on a big LaTeX buzz recently and even added support for it in comments there too!
janalsncm 2y ago
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.
- accrual 2y ago
  Could it be linear time? I thought larger inputs take longer for models to process. I suppose it depends on the length of each line and the number of lines.
- alwillis 2y ago
  See https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?pli=1&tab=t.0#heading=h.2djo7125fihp https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...
- deredede 2y ago
  Machine learning is not magic -- no algorithm, machine learning or otherwise, will be able to treat an arbitrary-length sequence in constant time. The actual problem is also more complex than fixed word widths due to hyphenation and justification - from what I recall, Knuth's paper (IIRC there's two and the second one is the one to read) on TeX's layout gives a good overview of the problem and an algorithm that's still state of the art. I think the Typst people might have a blog post about their modern take on it, but I'm not sure.
- ezfe 2y ago
  It can't be linear time. At best it would be log(n) but that would require storing all the possible inputs in a lookup table.
xnx 2y ago
Does different line wrapping result in difference in comprehension or reading speeds?
wruza 2y ago
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.
curtisszmania 2y ago
[dead]
donbrae 2y ago
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.
prmph 2y ago
Nice, but where is automatic ellipsis for multi-line text? Do the people spending time on these effort really talk to devs to determine what they find most critically missing and/or annoying about HTML?
eviks 2y ago
Would be nice if the first "bad" example was actually corrected and shown in the same blog that describes how it fixes the errors
pronik 2y ago
> 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 2y ago
  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.
- dspillett 2y ago
  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.
  - moogleii 2y ago
    Dig deeper. Use a shovel instead of a spade.
    - dspillett 2y ago
      Apple aren't the only ones to do is¹, of course, but it is definitely true. This enough digging for you? Go on. Vote down without offering a counter again. Take my fake points from me. You know it'll make you feel big. :) ---- [1] In true Apple style, people did it before, they polished the act a bit, and took it as theirs!
- marcellus23 2y ago
  You're not dumb but you didn't read the article.
aktau 2y ago
Does anyone know how this contrasts with `text-align: justify` (mentioned in https://news.ycombinator.com/item?id=43258709#43260606 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.
- cantSpellSober 2y ago
  `text-align: justify` solves a different problem, it justifies your text; both the left and right edges of each line are aligned with the margins. > Should one use both together in the main text of your average blog Optimize for legibility; the properties are compatible.
cantSpellSober 2y ago
Ironically the paragraph about orphans ("avoid leaving a single word by itself") puts "large" on a line by itself (at the largest viewport). Applying `text-wrap:pretty` solves that!
mac3n 2y ago
> 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

364 points by todsacerdoti 2y ago

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.

wruza 2y ago
I also do this for monospace text, but in proportional there's perfect "fill" justification which for some reason gets ignored. Here's how you do it in advanced layout systems like CSS: https://stackoverflow.com/questions/6205109/justify-text-to-fill-a-div https://stackoverflow.com/questions/6205109/justify-text-to-...

tiltowait 2y ago

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 2y ago
yeah, I agree, sometimes reading an ebook feels very off b/c of the lines just looking way too justified
MBCook 2y ago
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 2y ago
Sometimes I like to think Knuth may have intrusive violent thoughts about how shit programmers make text look.
- deleted 2y ago
  [deleted]
TiredOfLife 2y ago
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 2y ago
Given the way ebook software is developed, it'll be years before this makes it to a device near you.
- archagon 2y ago
  I dunno, I imagine Apple Books would be eager to implement this as soon as possible.
velcrovan 2y ago
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_ 2y ago
  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 2y ago
    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 https://en.wikipedia.org/wiki/Phototypesetting [2] https://en.wikipedia.org/wiki/Hot_metal_typesetting https://en.wikipedia.org/wiki/Hot_metal_typesetting [3] https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-breaking_algorithm https://en.wikipedia.org/wiki/Knuth%E2%80%93Plass_line-break...
  - aardvark179 2y ago
    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.
  - 2y ago
taeric 2y ago
Is this where folks will get it for ereaders? Naively, I hadn't realized ereaders were glorified webkit displays.
- mintplant 2y ago
  EPUB is HTML. https://www.w3.org/TR/epub-33/ https://www.w3.org/TR/epub-33/
  - taeric 2y ago
    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 2y ago
      CSS is your friend
      - taeric 2y ago
        The cascading aspect is mostly a big L. As is the dream of user style sheets. All the more so from the obfuscated style names so many tools saddle us with. Don't get me wrong, there are smart people working on css. That we decided, as an industry, to treat layout as a Rube Goldberg machination of interacting rules on a growing number of elements is not something you can easily overcome.

Eddy_Viscosity2 2y ago

Anybody know what font the article uses? I like it.

jsheard 2y ago
The sans is Apple's own SF Pro, and the code is SF Mono.
jasonjmcghee 2y ago
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.
- deleted 2y ago
  [deleted]
- ygra 2y ago
  Browsers typically say below the styles also which fonts are actually used (there can be multiple, e.g. when substitution is required to render certain characters).
sim04ful 2y ago
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 https://fontofweb.com to get their names. Disclaimer: I'm the creator

executesorder66 2y ago

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 https://caniuse.com/?search=text-wrap%20pretty How did that happen?

velcrovan 2y ago
It wasn't created by WebKit. WebKit is announcing (at last) support for it.
- executesorder66 2y ago
  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.
- alwillis 2y ago
  The WebKit implementation is the only one that can handle many pages of text with no noticeable performance hit, while Chrome and Firefox are limited to only dealing with the last 4 or 6 lines of a paragraph.
  - TiredOfLife 2y ago
    Firefox doesn't have this feature at all.
    - mrandish 2y ago
      I was curious as it seems like a nice thing to have and I use Firefox, so I looked it up. It's been suggested and you can upvote it here: https://connect.mozilla.org/t5/ideas/text-wrap-pretty-for-desktop-mobile/idi-p/63133 https://connect.mozilla.org/t5/ideas/text-wrap-pretty-for-de.... Per the last post there (Aug 24). > Mozilla standard position on this feature is positive > https://github.com/mozilla/standards-positions/issues/993 https://github.com/mozilla/standards-positions/issues/993

robszumski 2y ago

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

qingcharles 2y ago
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.

crazygringo 2y ago

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 2y ago
I hve no idea but it looks something like this https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122,0.004,1.106,0.419,0 https://www.loc.gov/resource/gdcwdl.wdl_03042/?sp=5&r=-0.122...
ameliaquining 2y ago
There's a TeX package that, among many other features, detects rivers: https://mirrors.ibiblio.org/pub/mirrors/CTAN/macros/latex/contrib/impnattypo/impnattypo.pdf 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 https://tex.stackexchange.com/a/736578
taeric 2y ago
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.

pradn 2y ago

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 2y ago
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/ https://practicaltypography.com/

throw0101d 2y ago

(La)Tex still seems to have the 'best' results for line breaking: * https://en.wikipedia.org/wiki/Knuth–Plass_line-breaking_algorithm https://en.wikipedia.org/wiki/Knuth–Plass_line-breaking_algo...

david2ndaccount 2y ago

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

IshKebab 2y ago

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 2y ago

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 2y ago
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 2y ago
  That's true, but I think the OP is commenting on the state of FE development :)
  - taeric 2y ago
    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 2y ago
  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 2y ago
    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.

fngjdflmdflg 2y ago

>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 2y ago
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 2y ago
  >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.

Sloppy 2y ago

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 2y ago
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/ https://practicaltypography.com/
- ashton314 2y ago
  MB over-engineered that book. Example: look at the paragraph that stars “But I don’t have visual skills” on this page: https://practicaltypography.com/why-does-typography-matter.html https://practicaltypography.com/why-does-typography-matter.h... Notice how the open quotation marks hang into the left margin. There’s been some recent work with CSS to make this automatic, but that’s newer than this book and support is spotty. MB made it happen with a (iirc) custom filter inside the Pollen setup he made for this book. Wild. And beautiful.
  - flobosg 2y ago
    See also the added soft hyphens within each word for hyphenation: https://practicaltypography.com/optional-hyphens.html#:~:text=For%20the%20hy%C2%ADphen%C2%ADation%20in%20this%20book https://practicaltypography.com/optional-hyphens.html#:~:tex...
    - OisinMoran 2y ago
      Ironically (or not) this section (on mobile anyway) seems to hyphenate way too much, with three lines in a row and two lines in a row ending in a hyphen (5/8 total lines in the paragraph).

intelliot 2y ago

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

tobr 2y ago
Good question, but keep in mind that it's claiming to `text-wrap: pretty`, not `text-wrap: comprehensible`. That should be enough!
- eviks 2y ago
  It's claiming both: > 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.

DadBase 2y ago

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

OisinMoran 2y ago

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-file 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 https://lynkmi.com/about Been on a big LaTeX buzz recently and even added support for it in comments there too!

janalsncm 2y ago

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.

accrual 2y ago
Could it be linear time? I thought larger inputs take longer for models to process. I suppose it depends on the length of each line and the number of lines.
alwillis 2y ago
See https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yTsvg8IuAq7oFrNQxPeqI/edit?pli=1&tab=t.0#heading=h.2djo7125fihp https://docs.google.com/document/d/1jJFD8nAUuiUX6ArFZQqQo8yT...
deredede 2y ago
Machine learning is not magic -- no algorithm, machine learning or otherwise, will be able to treat an arbitrary-length sequence in constant time. The actual problem is also more complex than fixed word widths due to hyphenation and justification - from what I recall, Knuth's paper (IIRC there's two and the second one is the one to read) on TeX's layout gives a good overview of the problem and an algorithm that's still state of the art. I think the Typst people might have a blog post about their modern take on it, but I'm not sure.
ezfe 2y ago
It can't be linear time. At best it would be log(n) but that would require storing all the possible inputs in a lookup table.

xnx 2y ago

Does different line wrapping result in difference in comprehension or reading speeds?

wruza 2y ago

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.

curtisszmania 2y ago

[dead]

donbrae 2y ago

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.

prmph 2y ago

Nice, but where is automatic ellipsis for multi-line text? Do the people spending time on these effort really talk to devs to determine what they find most critically missing and/or annoying about HTML?

eviks 2y ago

Would be nice if the first "bad" example was actually corrected and shown in the same blog that describes how it fixes the errors

pronik 2y ago

> 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 2y ago
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.
dspillett 2y ago
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.
- moogleii 2y ago
  Dig deeper. Use a shovel instead of a spade.
  - dspillett 2y ago
    Apple aren't the only ones to do is¹, of course, but it is definitely true. This enough digging for you? Go on. Vote down without offering a counter again. Take my fake points from me. You know it'll make you feel big. :) ---- [1] In true Apple style, people did it before, they polished the act a bit, and took it as theirs!
marcellus23 2y ago
You're not dumb but you didn't read the article.

aktau 2y ago

Does anyone know how this contrasts with `text-align: justify` (mentioned in https://news.ycombinator.com/item?id=43258709#43260606 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.

cantSpellSober 2y ago
`text-align: justify` solves a different problem, it justifies your text; both the left and right edges of each line are aligned with the margins. > Should one use both together in the main text of your average blog Optimize for legibility; the properties are compatible.

cantSpellSober 2y ago

Ironically the paragraph about orphans ("avoid leaving a single word by itself") puts "large" on a line by itself (at the largest viewport). Applying `text-wrap:pretty` solves that!

mac3n 2y ago

> 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