Adding the Hyperlegible font to this blog

Last updated: 23 days ago

Published: almost 2 years ago

raw source | baked source

Adding the Hyperlegible font to this blog required me to flex a few frontend muscles which I haven’t used in a while. Here’s how I did it.

NOTE: This concerns an older version of this website, back when it was published with Hugo. I still love Hyperlegible, though, and Vellum uses it by default. It’s still not served through Google Fonts, either.

But adding fonts is easy! You just…

No Google Fonts, please.

Oh. But why?

I don’t want to add external dependencies to this website. So far, I’m using Commento for comments, and I even feel bad about that. I’ve been using Plausible for analytics for a while, too, but I’m now dropping it in favor of reading logs with GoAccess.

More external dependencies almost always means more headaches. In my career, I’ve repeatedly had vendors die, cancel a subscription, fail to process payment and delete my entire account (yes really), go down, or just decide to blacklist a site because it dared to have traffic. I’m self-hosting this because I don’t want the headache; if CloudFront shutters today, this blog will be redeployed to a new server before you can say “huh, that’s weird”.

And so, I don’t want to introduce a dependency on an external property in general, and one owned by the Chocolate Factory in particular.

Adding fonts via CSS, 101

I realized something: it feels like I’ve always used Google Fonts, or at least something that managed exposing the fonts for me, like Webpack or Rails asset pipeline. To make a long story short - here are the magic incantations to add a font family to CSS:

1@font-face {
2    font-family: "hyperlegible";
3    font-weight: normal;
4    font-style: normal;
5    src: url("/Atkinson-Hyperlegible-Regular-102a.woff2") format('woff2');
6    font-display: block;
7}
8/* repeat for other variants of the font, four in total */

The only thing that could be non-obvious here is the font-display setting. The value of block should cause the browser to wait a short amount of time for the font to load, during which an invisible font is used, and then the loaded font is used normally.

But that will cause flash of invisible text!

Good old FOIT, we meet again. Not today, my friend: we come armed with <link preload>. I dropped this in the <head> section of this website:

1<link rel="preload" href="/Atkinson-Hyperlegible-Bold-102a.woff2" as="font" type="font/woff2" crossorigin>
2<link rel="stylesheet" href="/Atkinson-Hyperlegible-Bold-102a.woff2" type="font/woff2">
3<!-- repeat for other variants of the font -->

The rel="stylesheet" usage is a nasty hack for older browsers. It also helps for quieting down the warnings about unused fonts. Yes, they’re just warnings, but they bother me.

Integrating with Tailwind

This site uses Tailwind for its CSS. I found another reason to love it: reconfiguring fonts is a cinch. Here’s the relevant section of my config:

1theme: {
2  extend: {
3    fontFamily: {
4      'sans': ["hyperlegible", "ui-sans-serif", "system-ui", "-apple-system", "BlinkMacSystemFont", "Segoe UI", "Roboto", "Helvetica Neue", "Arial", "Noto Sans", "sans-serif", "Apple Color Emoji", "Segoe UI Emoji", "Segoe UI Symbol", "Noto Color Emoji"],
5    },
6  }
7}

I could have just added a hyperlegible font family, but I decided to override the existing sans family. Just in case something goes horribly wrong, the user agent will then have enough fonts to choose from and the site should still look somewhat passable.

Why Hyperlegible?

I discovered Hyperlegible in NetNewsWire and fell in love with it. It definitely improves my perceived readability of the news articles. Since I’m a blabbermouth, and my blog posts can easily run into hundreds if not thousands of words, I want the best reading experience possible. Hence, the decision to use it for this entire site.

What are your experiences with designing for readability? Feel free to share in the comments!


Comments (0)
Add a comment