[HN Gopher] An end to typographic widows on the web
___________________________________________________________________
An end to typographic widows on the web
Author : saeedesmaili
Score : 188 points
Date : 2023-03-13 11:16 UTC (11 hours ago)
(HTM) web link (clagnut.com)
(TXT) w3m dump (clagnut.com)
| LeanderK wrote:
| 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 wrote:
| There are JS plugins for it, example:
| 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."
| EvanDotPro wrote:
| 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.
| djha-skin wrote:
| 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
| phreack wrote:
| You're looking at the wrong part, the article refers to the
| title, where the widowed word is "working" on the bottom
| example
| sings wrote:
| The image you linked to is displaying correctly. Its the large
| headline that is wrapped differently, not the small body text.
| brxck wrote:
| The difference is in the headline, not the body text.
| dagorenouf wrote:
| 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 >>
| SquareWheel wrote:
| This solves a real problem for me. In the past I've used <wbr>
| 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 wrote:
| You can also use between the penultimate and the
| ultimate word, that doesn't require additional styling.
| brycewray wrote:
| 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.
| iamben wrote:
| 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 wrote:
| 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 wrote:
| But that alters the content, and copy/paste would carry that
| forced pairing into a different line-length context.
| whalesalad wrote:
| reminds me of this wonderfully named library from yesteryear -
| https://github.com/mogelbrod/widont
| hidelooktropic wrote:
| Until this happened, I've been using
| https://github.com/adamjgrant/Buddy-System
| strogonoff wrote:
| 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.
| kjeksfjes wrote:
| Combining text-wrap: balance with non-breaking spaces and word-
| joiners seems to be a good way to go. Also ­ is good to
| know.
| TAKEMYMONEY wrote:
| > _non-breaking spaces, word joiners, and other similar HTML
| entities_
|
| 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.
| strogonoff wrote:
| > 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.
| optimuspaul wrote:
| Off topic(?) but, "what next" in that sentence at all seems
| jarring. English is my first language so I could be wrong, but
| should it be "what's next" or "what is next"?
| reaperducer wrote:
| _I don't think in near term text-wrap: balance would be as good
| as human eye for headlines_
|
| 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.
| strogonoff wrote:
| I agree that it's better than nothing--merely saying that,
| based on the examples, it's not as good as the [more
| cumbersome] manual specification of preferred text wrapping
| points.
| philsnow wrote:
| 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.
| strogonoff wrote:
| Thanks for the illustration!
|
| 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.
| Kerrick wrote:
| ChatGPT can do it. Perhaps this won't be viable in-browser
| for a while, but I could see somebody using it in a static
| site build pipeline to convert space characters to
| at compile-time.
|
| ---
|
| 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"
| Arrath wrote:
| I've long been bugged by the lazy approach to
| plurals/multiples in e.g. game tooltips. "You loot 861
| gold(s)" I wonder if we'll ever see improvements on either
| front.
| ravenstine wrote:
| 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 wrote:
| 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!
| ericpauley wrote:
| Interestingly it appears ChatGPT is somewhat adept at this.
| Asking for the best ways to line-break this title, it suggests:
| "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?"
| edflsafoiewq wrote:
| Is there really no fast "good enough" algorithm for breaking body
| text?
| ughitsaaron wrote:
| How I would've loved to have this available when I worked at The
| New Yorker!
| cantSpellSober wrote:
| > _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.
| ashishb wrote:
| I built something similar for myself a few years back even adding
| colors to ensure faster reading.
|
| Demo:
| https://reading.ashishb.net/v1/readable/aHR0cHM6Ly93d3cudGhl...
| hcarvalhoalves wrote:
| 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 wrote:
| 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).
| copperx wrote:
| 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 wrote:
| Winter is coming.
| johnmorrison wrote:
| 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.
| gwern wrote:
| Chrome discussion:
| 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.
| webdevver wrote:
| I remember seeing someone linking a React component whos sole
| purpose was to balance text. Can't remember the name of it
| though...
| ilt wrote:
| Not exactly an "end" but appreciated nonetheless
| 2h wrote:
| 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.
| CJefferson wrote:
| 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 wrote:
| 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 `<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.
| [deleted]
| 2h wrote:
| Its not my problem to solve, that's the whole point. Its a
| niche enough need that it shouldn't even be part of CSS.
| people who have a need for it, should figure out some
| solution on their own, not force their complication onto the
| entire spec itself.
| karlshea wrote:
| This isn't niche at all, this has been a problem on many of
| the sites I've worked on. And the comment above is right,
| this is a rendering engine issue, there's not really much
| you can do as an end-user.
| frosted-flakes wrote:
| Any web designer with any degree of training in typography and
| text layout will recognize this as a problem. It's just that
| there's almost nothing we could do about it without CSS
| support, so everyone was forced to simply accept it.
| robertoandred wrote:
| This can't be solved well by the "end user", since it'd have to
| be done after the page loads.
| cmdialog wrote:
| 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 wrote:
| 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 wrote:
| 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.
| themodelplumber wrote:
| 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
|
| 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.
| hiccuphippo wrote:
| >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
|
| In this case the author is referring to the last definition,
| short lines at the end of a paragraph.
| weinzierl wrote:
| The traditional name for widow in German typography is
| _Hurenkind_ , literally "child of a whore".
| numlock86 wrote:
| The traditional name for orphan in German typography is
| _Schusterjunge_ , literally "shoemaker boy".
| brtkdotse wrote:
| Same in Sweden (or at least used to be) - _horunge_. If you
| have a widow on a new page that's a _dubbel horunge_.
| thunderbong wrote:
| Thanks, I kept thinking it was a typo in the title!
| quitit wrote:
| Yes this article is about orphans, not widows. However some
| people use the terms interchangeably.
|
| Widows don't exist without page or column divisions.
| latexr wrote:
| > 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.
| toastal wrote:
| Tangentially, I really want to see hanging-indent not be limited
| to WebKit
| dstroot wrote:
| 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
|
| It does add another dependency which I am not fond of.
| meindnoch wrote:
| Designers: "Why does this text look different in Firefox? Make it
| look like Chrome."
| danielvaughn wrote:
| 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 <br> 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!
| sings wrote:
| Even for static text, line breaks (<br>) can cause unexpected
| results unless you check at varying viewports. Non-breaking
| spaces may provide a better option, depending on the
| specifics of the situation.
| danielvaughn wrote:
| Yep, exactly. Though the sheer complexity of the problem
| makes me really curious how this is implemented under the
| hood. I'm surprised there aren't parameters devs can use to
| modify this behavior.
| Traubenfuchs wrote:
| Leaving stuff like this to be interpreted by the User-Agent is
| simply a tragedy.
| pornel wrote:
| This is why I have "Best viewed in Netscape 800x600" button
| on my page.
| urbandw311er wrote:
| 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.
| runarberg wrote:
| 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.
| Pxtl wrote:
| 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 wrote:
| If it were enabled by default then it would potentially change
| how older webpages were intended to render.
| vlmutolo wrote:
| > 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...
| cratermoon wrote:
| Original Knut-Plass paper:
| http://www.eprg.org/G53DOC/pdfs/knuth-plass-breaking.pdf
| thechao wrote:
| 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.
___________________________________________________________________
(page generated 2023-03-13 23:01 UTC)