Reimagining fluid typography | Miriam Suzanne

Whilst I've used fluid typography on several site designs (typically via Utopia's calculator), I've always been a bit wary about the base assumptions and potential accessibility issues that it can bring along. I'm far from the only one.

Miriam shares those concerns, and makes a very clear argument for why they exist and how we might go about resolving some of them. It's far from a silver bullet, but I really like the thinking behind this approach; it feels like a step in the right direction 😊

On the root assumption being made by current fluid type systems (e.g. Utopia):

Utopia asks us to start from a range of font sizes defined in px values, and then it does a conversion to rem by assuming that 1rem == 16px. As long as that assumption holds true, the math above will scale our font from an 18px minimum to a 20px maximum.

This is an assumption that developers often lean on, even when we’re not doing fluid math. It’s not an entirely reliable assumption, but it matches the default in most browsers, and things can feel pretty squishy if we don’t do some form of translation-to-pixels.

On why setting a base, global font size via the browser is becoming increasingly frustrating:

I see this situation play out over and over on the web. The lesson we often learn is users don’t set preferences, when the reality is that we applied their preferences badly. When the preference doesn’t do what I want, of course I have to stop using that preference.

On the core fallacy of modern web typography:

TL;DR – Never do pixel math with em and rem units. That’s where we went wrong, by assuming that 16px == 1em is a reliable fact.

But things always go wrong when we try to treat em as an alias for px, with mental conversions based on their assumed default relationship. At that point we’re keeping zoom, but discarding everything else about the user preference.

On why we shouldn't set a base font size on the html or body elements::

Don’t set a root font size. ... The best base font size is the user’s default font size – set in the browser.

On another fallacy that is common in web design circles, and one I also agree with ‒ heck, almost no one I know uses virtual desktops, without which I would also use overlapping, randomly sorted screens:

Again I’ve heard a common refrain that “users don’t resize their windows” – but I find that entirely unbelievable. In fact, I’d bet I’m in a very small minority by using mostly fullscreen apps.

On a potential solution, using a base range for your font size:

Instead we’re adding a slight responsiveness to the user value, and using the clamps to keep our fluid value within range of the user’s intent.

html { font-size: clamp(1em, 0.9em + 1vw, 1.5em); }

On a key way to self-check your own biases and patterns:

Any time you start doing mental math with 16px == 1em, stop yourself and ask if that math holds up over a whole range of user preferences.

(It doesn’t. Don’t do it.)

Explore Other Notes

Newer

"Fixing" lists

I've long "known" that if you set list-style: none on a <ul> or <ol>, then you "should" add role="list" to that element as well. If you don't, Safari/VoiceOver will ignore the inherent …

  • <p>Whilst I've used fluid typography on several site designs (typically via Utopia's calculator), I've always been a bit wary about the base assumptions and potential accessibility issues that it can …</p>
  • Murray Adcock.
Journal permalink