An end to typographic widows on the web
clagnut.com
clagnut.com
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.
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?
One year on and what next
for remote working?
I suppose the technology for more accurate automated line breaks should indeed be already available, though I don’t think it’ll be applied in this particular case quite soon so we’ll have to endure some awkward (even if a bit less ugly now with text-wrap: balance) word wrapping in meantime.
---
Break the following headlines up into individual strings where each string is an idiom that shouldn't be broken up. If words aren't part of an idiom, they can be their own string.
"One year on, and what's next for remote workers?"
"Hurricane Ida Gives New York What For!"
"Ice Town Costs Ice Clown His Town Crown"
---
"One year on" "and" "what's next" "for" "remote workers?"
"Hurricane Ida" "Gives" "New York" "What For!"
"Ice Town" "Costs" "Ice Clown" "His" "Town Crown"
This is truly the kind of suggestion that makes me wonder about the energy efficiency of websites.
To me it seems, that many web developers/designers are so happy with the fact that what they are doing actually works, they often forget other (more boring?) considerations like stability, maintainability, resilience, efficiency and such.
We have a LEGO set with infinite pieces and a good website in my eyes doesn't try to use as many as possible of those, but to use just as many as needed while still getting what you aim for.
This has the advantage that a human typesetter could output to this format as well or they could correct the machine generated output.
As there is a limited number of ways to break text the table wouldn't even have to store all pixel widths, just those at which the words break differently.
Ice Town Costs Renowned Ice Clown His Town Crown
and Gown
Ice Town Costs Renowned Ice Clown
His Town Crown and GownA few years ago, one of the localization team members gave me a tip I have been trying to stick to this time around.
Instead of "You found 1 coin." or "You found 2 coins." you turn it into an enumeration "Coins Found: 1"
The localization of the string part is the same for all languages.
Non-breaking spaces in some fonts are actually a different size than normal spaces, and most copy doesn't contain entities. Better for all if we can adjust the display of the text without programmers changing content.
It’s this awkward and awesome place where content and appearance meet. Whoever wrote the headline probably knows the exact meaning they wanted to convey, and ideally should have control over where the line would wrap just as they would expect to have a say in word emphasis or punctuation.
It doesn't need to contain entities. GP is not correct to refer to these characters as "HTML entities", which are just ways to conveniently express the characters in HTML. In fact these characters are Unicode characters just like all the other characters in the copy.
Though, in general, just a too long title that doesn't flow well without hints for where the pauses and inflections should be.
It's apparently very good for reading comprehension.
I've had a lot of training in this area, and while I don't understand why it is, all of the materials I've read — especially in the last ten years — say that orphaned words make sentences harder to understand.
That's interesting because my inclination is that "One Year On and What Next for Remove Working?" works best because "and" and "for" make it clear to me that the line is continued and that the current line isn't a complete clause.
"One year on and what next for remote working?" (original)
"One year on and what next for remote
working?"
"One year on and what next
for remote working?"
"One year on and
what next for remote working?">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
In this case the author is referring to the last definition, short lines at the end of a paragraph.
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.
Widows don't exist without page or column divisions.
Knuth-Plass isn’t quadratic. This post has some good explanations:
https://github.com/jaroslov/knuth-plass-thoughts/blob/master...
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.
But a CSS method is very welcome!
Same thing applies to client-side syntax highlighting and LaTeX.
I'm excited about this feature!
https://vercel.com/blog/react-wrap-balancer
It does add another dependency which I am not fond of.
I'm happy to read that it might finally happen with text-wrap: pretty.
> 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.
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
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.
Every time I use tex I just marvel how well it typesets text and fight with floating figures :)
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."
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 »
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.
Demo: https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhl...
Wonder how long this will take to land in the OBS browser where I actually needed it.
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.
Also PDF's have page breaks. And they're not interactive (usually).
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.
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.
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 `<br>`.
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
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.