Chris’ Corner: A Balancing Act

Posted on by

If you’re a super normal person like me, you’ve gone to war with typographic widows and orphans many times over your years as a developer, trying to ensure they don’t happen and ruin anyone’s day. You know what I mean, a headline with one silly little word that has wrapped down onto its own line. If only you could add a couple of soft returns in there to prevent it. You can, of course, but you know better. A soft return might fix a problem at one particular container width, that break causes an even more awkward problem at another container width.

One technique that is sometimes employed is to insert a   (non-breaking space) between the last two words (maybe even three?) of a headline (or paragraphs, if you’re nasty). 

This little piggy went to market

None of us can be troubled to hand-code that if we’re in charge of the HTML of headlines regularly. I wrote my own PHP to split headlines by word and manually insert the non-breaking space on CSS-Tricks a decade or more ago. It can be done in client-side JavaScript too, naturally, but nobody wants to see that reflow.

Finally, along comes the web platform with something that looks like a solution:

h1, h2, h3 {
  text-wrap: balance;
}

Tyler Sticka has an article about this new CSS and offers this clear comparison:

uh oh — at this width, we get an orphan
yay — no more orphan (or widow or whatever, my brain cannot learn which is which) with text-wrap: balance

That “balanced” headline nice, generally a much more pleasing result for multi-line headlines.

But notably, what is happening here isn’t explicitly orphan-fighting. Richard Rutter makes this clear in an article of his own:

What this is not is control over widows and orphans. My previous examples show how the text balancing algorithm in Chrome Canary does indeed prevent a widow (the single word dropped down), and that’s a highly likely outcome. But you have to remember that the balancing job shortens the lines, so this isn’t an approach you would take to prevent widows at the end of paragraphs. In fact Canary limits balancing to 4 lines.

So it works for avoiding orphans/widows, but almost as a side effect of the balancing. In a follow-up article, Richard shines a light on what could be a future answer:

Bit by bit, the CSSWG seems to have been converging on a potential solution. In the current draft of the CSS Text Module Level 4, there is mention of Last Line Minimum Length. …

Amelia Bellamy-Royds took the Last Line Minimum Length idea and proposed a solution with a new min-last-line property. Her proposed property would specify a minimum length for the final line, and a minimum length for the penultimate line once you’d dropped a word or more down to address the short final line.

Ship it. Especially if it works on paragraphs in multi-col.

✨ Outstanding blog post alert! ✨

Future CSS: Anchor Positioning by Roman Komarov.

We only have the most rudimentary way to “connecting” the position of two elements in CSS today. Take an element that has non-static positioning, and you can absolutely position an element within that context. That’s about it. Kinda sad when you think about it — especially as it comes up relatively often. Mostly in the context of tooltips and context menus, where you want an element (of arbitrary DOM position) to be positioned right next to the element that needs the tooltip or context menu.

This positioning challenge is usually done with JavaScript (the cow paths have been laid), by way of getBoundingClientRect and doing various geometric math to make sure the element doesn’t wank off the edge of the browser or in any way become “data loss” as we like to say in CSS. More challenging that it seems. Letting CSS do it seems awfully nice.

CSS tends not to focus solutions on one exact need though, preferring instead to solve the problem conceptually with primitives that might solve lots of use cases. This is where Roman gets clever with things and makes examples like this connecting elements with pointing arrows (involving SVG):

But also some cool demos with a slightly more practical twist, like moving highlight menus:

Jhey Tompkins’ article on this, Tether elements to each other with CSS anchor positioning, covers things from first principles and is probably a better reference for the syntax. But Jhey being Jhey, there are some weird and clever demos as well, like this emoji finger form:

It’s a Pen, naturally.

There is a <meter> element in HTML, and Dana Byerly does a great job of showcasing it. It’s a natural fit for stuff like “You’ve uploaded 47 of your maximum 100 files” in a visually more understandable way. There is some accessibilty stuff to get right though, including using “fallback text” (the text within the element) which is used by some screen readers and will certainly be useful context. Free basic styling is nice:

Live tests as a Pen, naturally.

I like the term “CSS micro-framework” as coined here by Blake Watson.

  • May include classes for building grids, components, etc. Typically limited, though, because of the next rule.
  • Under 10kb minified and gzipped. I feel like you can’t claim “micro” or “lightweight” beyond 10kb.
  • JavaScript is optional and is not supplied by the framework.

Examples:

They aren’t just a reset and they aren’t… Bootstrap. They aren’t necessarily “classless” either, which is a whole other category of framework that only styles things based on HTML selectors.

And then, another possible ending:

As we go deeper down the path of minimal CSS starters we end up at the logical conclusion—you might not need a framework at all.