9 ms·

An end to typographic widows on the web

207 points by saeedesmaili 4y ago

gwern 4y ago
Chrome discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/R__N3BdjAAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz... Apparently no evidence that Safari/Firefox will be implementing this any time soon. So don't get too excited unless you're fine with it only working for Chrome users.
toastal 4y ago
Tangentially, I really want to see hanging-indent not be limited to WebKit
edflsafoiewq 4y ago
Is there really no fast "good enough" algorithm for breaking body text?
hcarvalhoalves 4y ago
CSS and browser engines are increasingly complicated. Why not serve PDF and be done with it? Why reimplement complex typesetting, multiple times in different browsers, and why does it have to all happen on the client-side if you want pixel-perfect display anyway? This seem like an example of stretching a decision made decades ago far beyond the point it makes sense.
- crazygringo 4y ago
  In order to be responsive to different widths -- to work on a small phone screen and as 30" monitor. Also PDF's have page breaks. And they're not interactive (usually).
ashishb 4y ago
I built something similar for myself a few years back even adding colors to ensure faster reading. Demo: https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhlYXRsYW50aWMuY29tL3BvbGl0aWNzL2FyY2hpdmUvMjAxNi8wNC9jYW5jZXItdGhlLWZpbmFsLWZyb250aWVyLzQ3ODk2Mi8= https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhl...
cvladan 4y ago
Yes! Finally!
IYasha 4y ago
I still remember when CSS was such a promising thing... And now it'a wreck.
hiccuphippo 4y ago
>Widow >A paragraph-ending line that falls at the beginning of the following page or column, thus separated from the rest of the text. Mnemonically, a widow is "alone at the top" (of the family tree but, in this case, of the page). >Orphan >A paragraph-opening line that appears by itself at the bottom of a page or column, thus separated from the rest of the text. Mnemonically, an orphan is "alone at the bottom" (of the family tree but, in this case, of the page). >Alternately, a word, part of a word, or very short line that appears by itself at the end of a paragraph. Mnemonically still "alone at the bottom", just this time at the bottom of a paragraph. Orphans of this type give the impression of too much white space between paragraphs. https://en.wikipedia.org/wiki/Widows_and_orphans https://en.wikipedia.org/wiki/Widows_and_orphans In this case the author is referring to the last definition, short lines at the end of a paragraph.
- quitit 4y ago
  Yes this article is about orphans, not widows. However some people use the terms interchangeably. Widows don't exist without page or column divisions.
- thunderbong 4y ago
  Thanks, I kept thinking it was a typo in the title!
- latexr 4y ago
  > Mnemonically (…) The one that made me remember which is which was something like “a widow continues alone while an orphan is left behind”. In practice it makes little difference if you mix up the terms, since in context the problematic line will be visible.
- weinzierl 4y ago
  The traditional name for widow in German typography is Hurenkind , literally "child of a whore".
  - brtkdotse 4y ago
    Same in Sweden (or at least used to be) - horunge. If you have a widow on a new page that’s a dubbel horunge.
meindnoch 4y ago
Designers: "Why does this text look different in Firefox? Make it look like Chrome."
- Traubenfuchs 4y ago
 Leaving stuff like this to be interpreted by the User-Agent is simply a tragedy.
 - urbandw311er 4y ago
 I dunno… I kind of miss the days when every site wasn’t statically pixel perfect and text just sorta flowed around and did something sensible based on your browser window size, zoom level, etc. It allowed people to focus on the content over the presentation. But I can also understand the apprehension —- it feels like a recipe for arbitrary fragmentation.
 - pornel 4y ago
 This is why I have "Best viewed in Netscape 800x600" button on my page.
 - runarberg 4y ago
 I wonder if it is acceptable now because this is bound to be pretty dynamic across viewport sizes and resolutions. So perhaps they are allowing browsers to pick an algorithm they find best suited. Changing the algorithm afterwards will probably not break anything that wouldn’t be broken by a user shrinking their window.
- danielvaughn 4y ago
 lol yes, that's definitely going to happen. However, in this case, I think it's warranted. I've had so many incidents with designers, where they don't like how a line wraps, and want it to break at a more reasonable point. If the text is static, just toss in a and you're done. But with dynamic text, it's just not practical at all to try to fix, so I tell my designers that they have to live with it. I'm excited about this feature!
SquareWheel 4y ago
This solves a real problem for me. In the past I've used with white-space:nowrap set on the parent to help choose logical breaks in text, but it's tedious and requires DOM access. A simple CSS rule to automatically calculate this is very welcome. I'm not sure I like the name "pretty" for the second rule though. If they have to expose the algorithm (first-fit vs Knuth-Plass), I'd rather they choose more descriptive names.
- 9dev 4y ago
 You can also use   between the penultimate and the ultimate word, that doesn’t require additional styling.
 - iamben 4y ago
 This is my preferred method (now!). Also very simple to write a couple of lines of JavaScript to target P and H elements and replaces the last space with a non breaking space. But a CSS method is very welcome!
 - toastal 4y ago
 Please do this at build time instead of shipping to clients. You'll slow down page rendering, introduce a repaint, and now require a script. Considering all browsers will be doing the exact same execution, it's needlessly wasteful. Same thing applies to client-side syntax highlighting and LaTeX.
 - GavinMcG 4y ago
 But that alters the content, and copy/paste would carry that forced pairing into a different line-length context.
 - brycewray 4y ago
 In macOS, you can achieve this in plain text with [option]-[space]. Helpful in Markdown — although, of course, you can use ` ` in Markdown, as well.
ilt 4y ago
Not exactly an "end" but appreciated nonetheless
hidelooktropic 4y ago
Until this happened, I've been using https://github.com/adamjgrant/Buddy-System https://github.com/adamjgrant/Buddy-System
johnmorrison 4y ago
This is brilliant news and frankly should be the global default for headings if we were to start over - hopefully browsers will adapt this ASAP.
strogonoff 4y ago
Having some background in typesetting and typography, I don’t think in near term text-wrap: balance would be as good as human eye for headlines. In a sentence like “One year on and what next for remote working?”, “what next” is a stable phrase and breaking it up is jarring. Either of the below reads better: > One year on > and what next > for remote working? or: > One year on and what next > for remote working? (On the Web you can achieve those with non-breaking spaces, word joiners, and other similar HTML entities.) — As a hard rule with rare exceptions, don’t break after conjunctions or short modifying words such as “and”, “the”, “on”, etc.—carry them to the next line. — As a more vague rule of thumb, do not break after a word that is tightly coupled to the next one (this includes stable phrases and short idioms, adjective-noun combinations, and so on), unless intentionally for word play. Just one of those small things that together make for clean and readable headlines and GUI copy.
- ravenstine 4y ago
  If that's true, then it sounds like an excellent application for AI. Too bad I can't think of an existing model that you can just throw that problem at. There also seems to be next to no money in it for anyone looking to solve it that way.
  - strogonoff 4y ago
    Might make layout quite energy intensive, especially if this is applied to long body text—and it would certainly be done on the web if it gets as easy as setting a CSS property!
- philsnow 4y ago
  I don't have the same background, but it drives me nuts when I see phrases word-wrapped on awkward boundaries that don't make sense (especially in h1 elements, titles, headers, billboards, posters, etc etc etc). I'm just going to re-emphasize what you wrote because it's exactly the problem and I want to change the formatting a bit to make it clearer. In the article, the author shows that the headline with text-wrap:balance would look like this One year on and what next for remote working? , which breaks right in the middle of "what next". Much better (to my eyes) is wrapping the line along some larger syntactic boundary: One year on and what next for remote working? We have the technology to analyze sentences and figure out the syntactic structure. Preferring to break those sentences across larger parts of the syntax tree would make this text-wrapping property so much better.
2h 4y ago
this seems like something that should be left to end users to come up with a solution for. I would guess that a large percentage of web designers don't even know what this is, so adding it to the spec itself is just further bloating an already bloated spec. one thing I like about the Go language team, is they are not afraid to say "no" to proposals. it seems W3 forgot this tactic, long, long ago, and just rubber stamp anything coming from the Chrome team. Sad.
- cmdialog 4y ago
 Just stay in the back-end. Then you don't have to deal with these problems. Seems like you are having an opinion on an issue that doesn't really concern you for a reason that I can't seem to identify. Would you care to elaborate on why you care about the CSS typography spec?
 - 2h 4y ago
 thanks for your comment. I will make sure to never comment on a thread again, unless I am a world expert on the subject.
- creativenolo 4y ago
 Any web designer who has studied the minimum amount of typography would know this. And near every graphic designer know this. Near no web designers or graphic designers do this on the web, because they can’t. One persons bloat is another fundamentals.
- CJefferson 4y ago
 How could end users reasonably solve this? You can’t know exactly how text will be laid out, so I can only imagine using… canvas and doing your own font rendering? Which sounds horrible for all number of reasons.
 - ravenstine 4y ago
 More importantly, why should they? I mean, yeah, I guess giving end users that level of control is a good thing, just like how they can decide the default font style of their browser. But it's not the user's job to fix your web page. How text is rendered on a page is a result of intention. The web developer should be able to implement the design intent of a body of text and either allow it to widow where it makes sense or force the text to balance. The problem is that the tool for that simply doesn't exist without some JavaScript foolery, not that the user can't toggle something to make it happen. > so I can only imagine using… canvas and doing your own font rendering? Which sounds horrible for all number of reasons. It's both horrible and not. Canvas can be used merely to make appropriate calculations for text given that it is aware of the size of any font it is using. Rather than rendering with a canvas directly, it could be used to efficiently determine what the width of an element containing text should be to make it "balanced", and maybe where to stick ` `. This has basically nothing specifically to do with widowing, but I once implemented the approach of using canvas to do calculations for actual page text. The goal was to make it so that a given text would always fit the size of its containing element no matter how long the text. In other words, if the container has a fixed height and width, like if you wanted for whatever reason to render the Declaration Of Independence in a 300x300 div, it will find the correct font size to squeeze that whole thing into that div. https://codepen.io/Ravenstine/pen/QdRYeq https://codepen.io/Ravenstine/pen/QdRYeq Of course it will get slower the more text it has to calculate. Kinda tempted to see if WASM speeds it up any. I think it's a poor idea to try to polyfill text balancing in that way, but I think it can be done and in a way that doesn't sacrifice rendering actual text. EDIT: I realized I contradicted myself.
EvanDotPro 4y ago
Great timing. I was actually just complaining about this a couple weeks ago. Wonder how long this will take to land in the OBS browser where I actually needed it.
LeanderK 4y ago
I sometimes really hate how text wraps in browsers. It really limits beautiful designs. What is the current state...are there javascript libraries that could layout text? Or are the primitives not exposed enough to control the spacing and line breaks? Every time I use tex I just marvel how well it typesets text and fight with floating figures :)
- TAKEMYMONEY 4y ago
  There are JS plugins for it, example: https://opensource.adobe.com/balance-text/ https://opensource.adobe.com/balance-text/ There are also the CSS properties `widows` and `orphans`, they behave a bit differently than "the text is rendered so that the amount of text on each line is about the same."
ughitsaaron 4y ago
How I would’ve loved to have this available when I worked at The New Yorker!
cantSpellSober 4y ago
> What this is NOT is control over widows and orphans > this isn’t an approach you would take to prevent widows at the end of paragraphs Title is misleading, great to see progress here though. It can be difficult to get designers to accept fluidity in text however, especially headings. This is "determined by the rendering engine rather than any [...] CSS specification" so I'm concerned this will bring back bug tickets saying headings appear differently across browsers.
copperx 4y ago
It's 2023, the AI winter is over, and we still don't have Knuth-Plass in our web browsers or Kindles! I'm happy to read that it might finally happen with text-wrap: pretty.
- cratermoon 4y ago
  Winter is coming.
webdevver 4y ago
I remember seeing someone linking a React component whos sole purpose was to balance text. Can't remember the name of it though...
Pxtl 4y ago
1) I have so much trouble caring about issues like "typographic widows". 2) Wait, if this is actually important, why isn't it enabled by default instead of being yet another obscure CSS thing we need to know about? ... I realize these thoughts are somewhat contradictory.
- ravenstine 4y ago
  If it were enabled by default then it would potentially change how older webpages were intended to render.
djha-skin 4y ago
It's funny, I use Firefox on my phone and both of the examples ("normal" and "balanced") look exactly the same to me[1], with the line break between "savvy" and "businesses", but I gather from the text that they're not supposed to look the same. I get that the article is talking about blink browsers but it's also assuming that everyone has one. I suppose they should have put an image there instead of having the browser render it. 1: https://imgur.com/a/u2N3i9q https://imgur.com/a/u2N3i9q
- phreack 4y ago
  You're looking at the wrong part, the article refers to the title, where the widowed word is "working" on the bottom example
- sings 4y ago
  The image you linked to is displaying correctly. Its the large headline that is wrapped differently, not the small body text.
- brxck 4y ago
  The difference is in the headline, not the body text.
themodelplumber 4y ago
I remember how his niche-but-important topic was handled programmatically in the early days of blogging. Abstraction was sometimes provided in blogging software. For example, in Texpattern's TXP Tags there's a no_widow attribute that's been there since pre-2008 I think? https://docs.textpattern.com/tags/title https://docs.textpattern.com/tags/title It's funny to remember all the typographic fixes that effectively took place in PHP due to CSS solutions being planned but not ready yet. I'll bet a lot of them are still functioning in various sites out there.
vlmutolo 4y ago
> Algorithms such as Knuth-Plass won’t necessarily eliminate widows and orphans, but might go some way to doing so. The reluctance to using such approaches is understandable, however, as they can be extremely demanding: the processing requirements increase quadratically with the paragraph length. Knuth-Plass isn’t quadratic. This post has some good explanations: https://github.com/jaroslov/knuth-plass-thoughts/blob/master/plass.md https://github.com/jaroslov/knuth-plass-thoughts/blob/master...
- thechao 4y ago
  Jeremy Gibbons et al. invented this; I just wrote this up because Jeremy's a really amazing scientist & I think his work should be appreciated, more.
- cratermoon 4y ago
  Original Knut-Plass paper: http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf
dstroot 4y ago
Just sharing that there is a react component I have used called "React Wrap Balancer" from Vercel that does something similar and works today: https://vercel.com/blog/react-wrap-balancer https://vercel.com/blog/react-wrap-balancer It does add another dependency which I am not fond of.
whalesalad 4y ago
reminds me of this wonderfully named library from yesteryear - https://github.com/mogelbrod/widont https://github.com/mogelbrod/widont
dagorenouf 4y ago
We need a rule to stop breaking up the words and their determiners too. (Wife is a typographer) Something like: « Wikipedia is a multilingual free online encyclopedia written and maintained by a community of volunteers » Would be better as: « Wikipedia is a multilingual free online encyclopedia written and maintained by a community of volunteers »

207 points by saeedesmaili 4y ago

Chrome discussion: https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz6PIXaI/m/R__N3BdjAAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/f5eLz... Apparently no evidence that Safari/Firefox will be implementing this any time soon. So don't get too excited unless you're fine with it only working for Chrome users.

toastal 4y ago

Tangentially, I really want to see hanging-indent not be limited to WebKit

edflsafoiewq 4y ago

Is there really no fast "good enough" algorithm for breaking body text?

hcarvalhoalves 4y ago

CSS and browser engines are increasingly complicated. Why not serve PDF and be done with it? Why reimplement complex typesetting, multiple times in different browsers, and why does it have to all happen on the client-side if you want pixel-perfect display anyway? This seem like an example of stretching a decision made decades ago far beyond the point it makes sense.

crazygringo 4y ago
In order to be responsive to different widths -- to work on a small phone screen and as 30" monitor. Also PDF's have page breaks. And they're not interactive (usually).

ashishb 4y ago

I built something similar for myself a few years back even adding colors to ensure faster reading. Demo: https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhlYXRsYW50aWMuY29tL3BvbGl0aWNzL2FyY2hpdmUvMjAxNi8wNC9jYW5jZXItdGhlLWZpbmFsLWZyb250aWVyLzQ3ODk2Mi8= https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhl...

cvladan 4y ago

Yes! Finally!

IYasha 4y ago

I still remember when CSS was such a promising thing... And now it'a wreck.

hiccuphippo 4y ago

>Widow >A paragraph-ending line that falls at the beginning of the following page or column, thus separated from the rest of the text. Mnemonically, a widow is "alone at the top" (of the family tree but, in this case, of the page). >Orphan >A paragraph-opening line that appears by itself at the bottom of a page or column, thus separated from the rest of the text. Mnemonically, an orphan is "alone at the bottom" (of the family tree but, in this case, of the page). >Alternately, a word, part of a word, or very short line that appears by itself at the end of a paragraph. Mnemonically still "alone at the bottom", just this time at the bottom of a paragraph. Orphans of this type give the impression of too much white space between paragraphs. https://en.wikipedia.org/wiki/Widows_and_orphans https://en.wikipedia.org/wiki/Widows_and_orphans In this case the author is referring to the last definition, short lines at the end of a paragraph.

quitit 4y ago
Yes this article is about orphans, not widows. However some people use the terms interchangeably. Widows don't exist without page or column divisions.
thunderbong 4y ago
Thanks, I kept thinking it was a typo in the title!
latexr 4y ago
> Mnemonically (…) The one that made me remember which is which was something like “a widow continues alone while an orphan is left behind”. In practice it makes little difference if you mix up the terms, since in context the problematic line will be visible.
weinzierl 4y ago
The traditional name for widow in German typography is Hurenkind , literally "child of a whore".
- brtkdotse 4y ago
  Same in Sweden (or at least used to be) - horunge. If you have a widow on a new page that’s a dubbel horunge.

meindnoch 4y ago

Designers: "Why does this text look different in Firefox? Make it look like Chrome."

Traubenfuchs 4y ago
Leaving stuff like this to be interpreted by the User-Agent is simply a tragedy.
- urbandw311er 4y ago
  I dunno… I kind of miss the days when every site wasn’t statically pixel perfect and text just sorta flowed around and did something sensible based on your browser window size, zoom level, etc. It allowed people to focus on the content over the presentation. But I can also understand the apprehension —- it feels like a recipe for arbitrary fragmentation.
- pornel 4y ago
  This is why I have "Best viewed in Netscape 800x600" button on my page.
- runarberg 4y ago
  I wonder if it is acceptable now because this is bound to be pretty dynamic across viewport sizes and resolutions. So perhaps they are allowing browsers to pick an algorithm they find best suited. Changing the algorithm afterwards will probably not break anything that wouldn’t be broken by a user shrinking their window.
danielvaughn 4y ago
lol yes, that's definitely going to happen. However, in this case, I think it's warranted. I've had so many incidents with designers, where they don't like how a line wraps, and want it to break at a more reasonable point. If the text is static, just toss in a and you're done. But with dynamic text, it's just not practical at all to try to fix, so I tell my designers that they have to live with it. I'm excited about this feature!

SquareWheel 4y ago

This solves a real problem for me. In the past I've used with white-space:nowrap set on the parent to help choose logical breaks in text, but it's tedious and requires DOM access. A simple CSS rule to automatically calculate this is very welcome. I'm not sure I like the name "pretty" for the second rule though. If they have to expose the algorithm (first-fit vs Knuth-Plass), I'd rather they choose more descriptive names.

9dev 4y ago
You can also use   between the penultimate and the ultimate word, that doesn’t require additional styling.
- iamben 4y ago
  This is my preferred method (now!). Also very simple to write a couple of lines of JavaScript to target P and H elements and replaces the last space with a non breaking space. But a CSS method is very welcome!
  - toastal 4y ago
    Please do this at build time instead of shipping to clients. You'll slow down page rendering, introduce a repaint, and now require a script. Considering all browsers will be doing the exact same execution, it's needlessly wasteful. Same thing applies to client-side syntax highlighting and LaTeX.
- GavinMcG 4y ago
  But that alters the content, and copy/paste would carry that forced pairing into a different line-length context.
- brycewray 4y ago
  In macOS, you can achieve this in plain text with [option]-[space]. Helpful in Markdown — although, of course, you can use ` ` in Markdown, as well.

ilt 4y ago

Not exactly an "end" but appreciated nonetheless

hidelooktropic 4y ago

Until this happened, I've been using https://github.com/adamjgrant/Buddy-System https://github.com/adamjgrant/Buddy-System

johnmorrison 4y ago

This is brilliant news and frankly should be the global default for headings if we were to start over - hopefully browsers will adapt this ASAP.

strogonoff 4y ago

Having some background in typesetting and typography, I don’t think in near term text-wrap: balance would be as good as human eye for headlines. In a sentence like “One year on and what next for remote working?”, “what next” is a stable phrase and breaking it up is jarring. Either of the below reads better: > One year on > and what next > for remote working? or: > One year on and what next > for remote working? (On the Web you can achieve those with non-breaking spaces, word joiners, and other similar HTML entities.) — As a hard rule with rare exceptions, don’t break after conjunctions or short modifying words such as “and”, “the”, “on”, etc.—carry them to the next line. — As a more vague rule of thumb, do not break after a word that is tightly coupled to the next one (this includes stable phrases and short idioms, adjective-noun combinations, and so on), unless intentionally for word play. Just one of those small things that together make for clean and readable headlines and GUI copy.

ravenstine 4y ago
If that's true, then it sounds like an excellent application for AI. Too bad I can't think of an existing model that you can just throw that problem at. There also seems to be next to no money in it for anyone looking to solve it that way.
- strogonoff 4y ago
  Might make layout quite energy intensive, especially if this is applied to long body text—and it would certainly be done on the web if it gets as easy as setting a CSS property!
philsnow 4y ago
I don't have the same background, but it drives me nuts when I see phrases word-wrapped on awkward boundaries that don't make sense (especially in h1 elements, titles, headers, billboards, posters, etc etc etc). I'm just going to re-emphasize what you wrote because it's exactly the problem and I want to change the formatting a bit to make it clearer. In the article, the author shows that the headline with text-wrap:balance would look like this One year on and what next for remote working? , which breaks right in the middle of "what next". Much better (to my eyes) is wrapping the line along some larger syntactic boundary: One year on and what next for remote working? We have the technology to analyze sentences and figure out the syntactic structure. Preferring to break those sentences across larger parts of the syntax tree would make this text-wrapping property so much better.

2h 4y ago

this seems like something that should be left to end users to come up with a solution for. I would guess that a large percentage of web designers don't even know what this is, so adding it to the spec itself is just further bloating an already bloated spec. one thing I like about the Go language team, is they are not afraid to say "no" to proposals. it seems W3 forgot this tactic, long, long ago, and just rubber stamp anything coming from the Chrome team. Sad.

cmdialog 4y ago
Just stay in the back-end. Then you don't have to deal with these problems. Seems like you are having an opinion on an issue that doesn't really concern you for a reason that I can't seem to identify. Would you care to elaborate on why you care about the CSS typography spec?
- 2h 4y ago
  thanks for your comment. I will make sure to never comment on a thread again, unless I am a world expert on the subject.
creativenolo 4y ago
Any web designer who has studied the minimum amount of typography would know this. And near every graphic designer know this. Near no web designers or graphic designers do this on the web, because they can’t. One persons bloat is another fundamentals.
CJefferson 4y ago
How could end users reasonably solve this? You can’t know exactly how text will be laid out, so I can only imagine using… canvas and doing your own font rendering? Which sounds horrible for all number of reasons.
- ravenstine 4y ago
 More importantly, why should they? I mean, yeah, I guess giving end users that level of control is a good thing, just like how they can decide the default font style of their browser. But it's not the user's job to fix your web page. How text is rendered on a page is a result of intention. The web developer should be able to implement the design intent of a body of text and either allow it to widow where it makes sense or force the text to balance. The problem is that the tool for that simply doesn't exist without some JavaScript foolery, not that the user can't toggle something to make it happen. > so I can only imagine using… canvas and doing your own font rendering? Which sounds horrible for all number of reasons. It's both horrible and not. Canvas can be used merely to make appropriate calculations for text given that it is aware of the size of any font it is using. Rather than rendering with a canvas directly, it could be used to efficiently determine what the width of an element containing text should be to make it "balanced", and maybe where to stick ` `. This has basically nothing specifically to do with widowing, but I once implemented the approach of using canvas to do calculations for actual page text. The goal was to make it so that a given text would always fit the size of its containing element no matter how long the text. In other words, if the container has a fixed height and width, like if you wanted for whatever reason to render the Declaration Of Independence in a 300x300 div, it will find the correct font size to squeeze that whole thing into that div. https://codepen.io/Ravenstine/pen/QdRYeq https://codepen.io/Ravenstine/pen/QdRYeq Of course it will get slower the more text it has to calculate. Kinda tempted to see if WASM speeds it up any. I think it's a poor idea to try to polyfill text balancing in that way, but I think it can be done and in a way that doesn't sacrifice rendering actual text. EDIT: I realized I contradicted myself.

EvanDotPro 4y ago

Great timing. I was actually just complaining about this a couple weeks ago. Wonder how long this will take to land in the OBS browser where I actually needed it.

LeanderK 4y ago

I sometimes really hate how text wraps in browsers. It really limits beautiful designs. What is the current state...are there javascript libraries that could layout text? Or are the primitives not exposed enough to control the spacing and line breaks? Every time I use tex I just marvel how well it typesets text and fight with floating figures :)

TAKEMYMONEY 4y ago
There are JS plugins for it, example: https://opensource.adobe.com/balance-text/ https://opensource.adobe.com/balance-text/ There are also the CSS properties `widows` and `orphans`, they behave a bit differently than "the text is rendered so that the amount of text on each line is about the same."

ughitsaaron 4y ago

How I would’ve loved to have this available when I worked at The New Yorker!

cantSpellSober 4y ago

> What this is NOT is control over widows and orphans > this isn’t an approach you would take to prevent widows at the end of paragraphs Title is misleading, great to see progress here though. It can be difficult to get designers to accept fluidity in text however, especially headings. This is "determined by the rendering engine rather than any [...] CSS specification" so I'm concerned this will bring back bug tickets saying headings appear differently across browsers.

copperx 4y ago

It's 2023, the AI winter is over, and we still don't have Knuth-Plass in our web browsers or Kindles! I'm happy to read that it might finally happen with text-wrap: pretty.

cratermoon 4y ago
Winter is coming.

webdevver 4y ago

I remember seeing someone linking a React component whos sole purpose was to balance text. Can't remember the name of it though...

Pxtl 4y ago

1) I have so much trouble caring about issues like "typographic widows". 2) Wait, if this is actually important, why isn't it enabled by default instead of being yet another obscure CSS thing we need to know about? ... I realize these thoughts are somewhat contradictory.

ravenstine 4y ago
If it were enabled by default then it would potentially change how older webpages were intended to render.

djha-skin 4y ago

It's funny, I use Firefox on my phone and both of the examples ("normal" and "balanced") look exactly the same to me[1], with the line break between "savvy" and "businesses", but I gather from the text that they're not supposed to look the same. I get that the article is talking about blink browsers but it's also assuming that everyone has one. I suppose they should have put an image there instead of having the browser render it. 1: https://imgur.com/a/u2N3i9q https://imgur.com/a/u2N3i9q

phreack 4y ago
You're looking at the wrong part, the article refers to the title, where the widowed word is "working" on the bottom example
sings 4y ago
The image you linked to is displaying correctly. Its the large headline that is wrapped differently, not the small body text.
brxck 4y ago
The difference is in the headline, not the body text.

themodelplumber 4y ago

I remember how his niche-but-important topic was handled programmatically in the early days of blogging. Abstraction was sometimes provided in blogging software. For example, in Texpattern's TXP Tags there's a no_widow attribute that's been there since pre-2008 I think? https://docs.textpattern.com/tags/title https://docs.textpattern.com/tags/title It's funny to remember all the typographic fixes that effectively took place in PHP due to CSS solutions being planned but not ready yet. I'll bet a lot of them are still functioning in various sites out there.

vlmutolo 4y ago

> Algorithms such as Knuth-Plass won’t necessarily eliminate widows and orphans, but might go some way to doing so. The reluctance to using such approaches is understandable, however, as they can be extremely demanding: the processing requirements increase quadratically with the paragraph length. Knuth-Plass isn’t quadratic. This post has some good explanations: https://github.com/jaroslov/knuth-plass-thoughts/blob/master/plass.md https://github.com/jaroslov/knuth-plass-thoughts/blob/master...

thechao 4y ago
Jeremy Gibbons et al. invented this; I just wrote this up because Jeremy's a really amazing scientist & I think his work should be appreciated, more.
cratermoon 4y ago
Original Knut-Plass paper: http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf

dstroot 4y ago

Just sharing that there is a react component I have used called "React Wrap Balancer" from Vercel that does something similar and works today: https://vercel.com/blog/react-wrap-balancer https://vercel.com/blog/react-wrap-balancer It does add another dependency which I am not fond of.

whalesalad 4y ago

reminds me of this wonderfully named library from yesteryear - https://github.com/mogelbrod/widont https://github.com/mogelbrod/widont

dagorenouf 4y ago

We need a rule to stop breaking up the words and their determiners too. (Wife is a typographer) Something like: « Wikipedia is a multilingual free online encyclopedia written and maintained by a community of volunteers » Would be better as: « Wikipedia is a multilingual free online encyclopedia written and maintained by a community of volunteers »