We call type “fluid” when the text on a web page scales smoothly in relation to screen size without any breakpoints. If, like me, you've just had a marathon catch-up with all things web typography in 2021, the most thrilling part about this concept would seem to be the immense gains in code maintainability.

Articles on fluid type often introduce the topic by explaining how it can remove complexity in styling¹. One example:

I wanted to reduce the number of media-queries, but maintain responsiveness. I wanted to reduce the CSS footprint of the website. But above all, I wanted to make my CSS more maintainable. Adding fluidity for font-sizes, element sizes, and spacing contributed to achieving this goal.

A better developer experience is valuable in its own right. But—compared to a well-executed breakpoint-based design—what exactly is the UX impact of fully fluid type?

Nothing much, is the short answer. A thoughtfully implemented fluid type system won't affect users in any meaningful way—positive or negative. Maybe that's why discussions on fluid type often just gloss over readability. Plain and simple, it really is mostly about the technical optimisations it affords.

Still, even if subtle, I can't help but wonder about how fluidity in design impacts people, and how it matches our expectations of using the web. So, here are my thoughts and findings—some concrete, stemming from visual design and typographic theory, and some of my own (wild?) speculation.

Fluid sizing vs breakpoint-based sizing

Let's start by getting size—and why it's not what matters here—out of the way.

First, the obvious: fluid typography is less about the outcome, and more about doing the same thing in a slightly different way. Imagine a breakpoint-based website that shows 14px text on mobile and 22px text on desktop. After you ditch the media queries and scale the text fluidly from 14px to 22px, a lot of people will still go on seeing roughly 14px text on mobile and 22px text on desktop.

It's the in-between screen sizes where fluidity makes more of a difference. But here, I think everyone can agree that text set at 17.6px on a 540px screen and scaled down to 15.2px on a 414px screen is not fundamentally better than showing 16px text on both. We must remember that screen width is only a convenient proxy to a much richer and unpredictable viewing context, which, at this level of tiny adjustments, will likely undo any efforts to make sizing perfect.

Can we count on context? Can we assume that everyone holds a phone or tablet at the same distance, or that desktop browsers are all hunched over a desk? […] Until computers sense a user's reading distance and adjust page scale proportionally (sounds like a nightmare, right?) we'll have to make these sensible generalizations.

Looking at where fluid font sizing can go wrong, the danger is tying it too intimately to the viewport, resulting in text that becomes too small or too big too fast. In 2021, though, this is mostly a non-issue. With the help of new CSS features, smart implementations avoid extreme scaling by only “sprinkling” the calculation with a tiny viewport multiple, and clamping it to a reasonable minimum and maximum—all the while keeping everything accessible!

body {
  font-size: clamp(1rem, 0.5rem + 2vw, 1.625rem);
}

So—fluid typography, if carefully implemented, won't harm readability. But it also doesn't have much of an edge over a handful of well-chosen breakpoints and font sizes.

Display text and line length

I tried and failed to find many specific areas where viewport-relative typography does outperform breakpoint-based sizing in terms of readability. Here are two: setting display text and maintaining consistent measure.

• Display text

  Large textual elements such as titles or bold visual statements look more striking when they are tied to the viewport size. Richart Rutter puts it nicely when he says that “display text, as defined by its purpose and relative size, is text to be seen first, and read second”.

  In other words a picture of text. When it comes to pictures, you are likely to scale all scene-setting imagery – cover photos, hero images, and so on – relative to the viewport. Take the same approach with display text: lock the size and shape of the text to the screen or browser window.

• Consistent measure (line length)

  It's widely known that there exists an optimal line length (measured in words or characters) for comfortable reading. Line length can be unpredictable at different screen widths for text whose size is static.

Viewport-relative sizing easily addresses both of these concerns². It's worth pointing out, though, that while it's probably the obvious solution for setting display text (unless you're happy with JavaScript), it's by far not the only alternative for achieving consistent line length. In addition to good old media queries to control text container sizing³, you can also use the ch unit to specify a max-length for a block of text. Ultimately, don't forget that on screens, there is a relatively wide range on line length where reading comfort isn't compromised, and it's not necessarily tied to text size.

When designing a responsive website, start with a comfortable font size and an ideal measure to help determine break points. But when the time comes (as it always does), let the ideal measure go.

A note on accessibility

Allowing people to retain control over the font size displayed in their browser is one of the most basic of accessibility requirements. Matej Latin thoroughly compared the pros and cons of different fluid type approaches in The State of Fluid Web Typography, and many of them feature issues of accessibility. As mentioned above, it is possible to make fluid typography accessible by combining viewport units with rem or em (preferably rem)—this ensures text zooming is functional and that the browser's default font size is respected.

Still, Latin's line of thinking resonates with me:

We shouldn't be focusing on making our font sizes scale nicely for every screen width. We should make our texts easy and enjoyable to read to each and every one of our users. This means leaving some of the control over web typography in their hands. At this moment, fluid web typography interferes too much with that.

This rings true even for fluid type that ticks the accessibility boxes. It's especially relevant when laptop/desktop users resize their browser—more on that later.

I'd be very interested to hear of more readability-related cases for or against fluid text sizing. As it stands, I'm not convinced there is a strong argument.

Next, let me shift focus from the text itself to the interface as a whole. Can the extent to which fluidity is applied create unexpected usability issues?

Fluid type or fluid interface?

Similarly to readability, how much of the content on your site should scale fluidly is something I rarely find discussed. Perhaps you consider fluidity important only for display text, as suggested above; maybe it's all the body copy so that you can maintain consistent line lengths. There's the option of making type fluid only on handheld devices, where there's less room for drastic layout changes across sizes⁴.

I'm keen to hear if there are best practices here that I've missed, but it seems to me that applying fluidity anywhere can easily trickle down to the entire interface (especially if the aim is to have fewer breakpoints). Having scaled the font size, you need to scale line heights and spacing around elements. But most interface elements contain some text; you go around adding a vw here, a vmin there, and suddenly the majority of your interface is fluid.

At the extreme, this can result in a design that scales fully proportionally and maintains its aspect ratios everywhere. It's as if you're looking at a picture of a website, not a live interface.

Common sense says that most uses of fluidity will fall somewhere in the middle of that spectrum. Still, it's interesting to speculate on how full fluidity might end up harming usability.

Resizing windows

Everyone resizes their windows. Your site's visitors are probably not doing it to scrutinise your responsive design, but there may be other, very practical reasons at play.

I make a window bigger when I want to see more information, not the same information presented in a larger size. A reason for making windows smaller might be wanting to fit multiple windows next to each other and work with all of them simultaneously (think task-based workflows such as editing in one window and viewing references in another). I have no data to back this up, but my intuition says that it's the amount of available space, not the size of visible content, that people are playing with when they resize windows.

When I imagine a fully fluid interface, I'm reminded of how Frank Chimero describes edgelessness as a core characteristic of designing for the web. A fully fluid interface will stubbornly stick to its edges, choosing to scale its content instead of adjusting its layout. To me, this feels annoying in the same way that scrolljacking feels annoying. To use Chimero's terms, it goes against the grain.

Taking a step back—as mentioned before, using viewport-relative units for just your text and scaling the whole design proportionally are very different things. But in all cases it's worth considering for a moment how and whether people expect content to scale during resizing. Browsing a blog? It probably doesn't matter. Referencing a dense data table while working in a separate window? Maybe don't go crazy with fluidity.

One (fluid) size fits all

I'm verging on the hypothetical now, but for the sake of argument, here's a final thought on how excessive fluidity in interfaces can negatively impact UX: the loss of pressure on developers to adapt the design.

If things scale proportionally and line breaks stay where they ought to, everything technically looks great on a wide array of screen sizes. At the extreme, you might get away with separate mobile and desktop layouts, with everything in between relying on fluidity.

But this goes back to the previous point about people wanting to see more content, not the same content bigger. The extra space afforded by larger screens should be seen as an opportunity to adjust the layout so the viewer can take full advantage of their screen real estate. Conversely, on small screens, with a fluid interface you can juuuuust push at the boundary of what's acceptable, because everything fits, after all.

How large should images be? When does the site look awkward & disjointed? When do things get too large? Is it appropriate to slide this layout's columns out into additional sidebars […]?

It's not that anyone would purposefully neglect responsive design. But it does become easier for things to count as passable. At the very least, subtly adjusting designs for many screen sizes (“tweak till you're cross-eyed”, in Walton's words³) is an outlet for creativity and craftsmanship, and it would be a shame to start seeing less of that.

To recap: I explained why fluid font sizing isn't inherently better or worse for UX, aside from a couple of minor, specific areas. I also speculated on how excessive fluidity can become problematic. Many of the issues raised are subtle, but I wanted to raise them nonetheless and add to what otherwise feels like a developer-centric discussion.

Personally, I'm happy to stay with responsive approaches for now. I do want to make a point of endorsing fluid type and its simplicity: it's a clever technique that when thoughtfully implemented can create beautiful typography that scales exactly where you want it to, challenging the view that dimensions on the web should be fixed. But as it stands, I'm not convinced the value added is worthwhile.