Responsive Typography Requirements

With all of these requirements to make web typography work in an ideal way across different screen sizes, I wrote down the core features I wanted to achieve using CSS.

Using CSS, be able to:

Define one or more modular scales to be used.

Redefine a modular scale based on device width using media queries. Reason for this being that I want to use a different modular scale to make the text look clear and readable on different screen sizes.

Have the text and its corresponding line-height scale elastically as the screen width changes, in order to preserve an ideal number of characters on each line and keep legibility consistent.

I came up with 4 different options, each with its own pros and cons regarding which requirements they fulfilled as well as browser support.

Option A: SCSS mixin for modular scales

Allows me to define a modular scale with SCSS variables, as well as using the modular scale to calculate font-sizes for different headings. Example:

Line-heights can be calculated and written directly in the CSS. Since setting line-heights can be sort of nit-picky work, depending on your chosen base font-size, typeface and screen size I’ve not declared these in the above example. If you know of a mixin or other tool that can take in as much information as possible (like base font-size, min- and max font-sizes, typeface x-height, modular scales and screen size breakpoints) and poop out the best possible line-height, that would be awesome. Let me know and I’ll update the article!

Advantage

The CSS produced will be compatible with all browsers that can handle media queries, which means browser support is pretty solid all the way back to Internet Explorer 9. Internet Explorer 8 support could be achieved using polyfills like modernizr with respond.

Con

There is no elastic scaling of text as the screen width changes.

When to Use

Use when you need to support really old browsers, or are unsure about how old browsers you need to support.

Option B: CSS Variables for modular scales

The SCSS variables in the Option A example can be switched for CSS variables. Using calc() to add units as well as multiplying the scales allows us to put the calculations directly in the property declaration.

Advantage

In my opinion, the biggest advantage of using CSS variables over SCSS variables in this case, would be that the code is simpler and does not require any compiling. Also, if you wanted to manipulate the variables dynamically it is easier to do so with CSS variables compared to altering compiled SCSS variables.

Con

Even if CSS properties are supported in all major modern browsers back to Edge 16, you will need to provide fallbacks for older browsers. Have a look at the previous blog post CSS Variables or Custom Properties for some tips on how to do that.

When to Use

When you either want to change the values dynamically at a later time, or you are very certain you only have to provide support for modern browsers.

Option C: SCSS mixin combined with modular scale in SCSS

A few years ago, Mike Riethmuller presented a way of achieving what he called fluid typography – text that scales with the viewport width. The formula leans on CSS calc(), and works in essence like this:

calc($min-font-size + ($max-font-size - $min-font-size) * (100vw - $min-screen-size) / ($max-screen-size - $min-screen-size));
/*
$min-font-size and $max-font-size represent the smallest and largest size you want the text to be
$min-screen-size and $max-screen-size represent the screen sizes between which the text starts and stops scaling
*/

The SCSS variables in the code above are meant to be exchanged for numbers selected by the user and fed into the mixin.

By adding SCSS variables to handle modular scales at different breakpoints, as well as some extra lines of code to handle line-heights, margins and fallbacks for older browsers, all of the requirements listed at the top are fulfilled. More detailed comments are in the code below:

Advantage

The code gets a little less complex and slightly DRY’er compared to the same technique written in SCSS. The CSS is modern and should be easier to maintain in the future.

Con

Browser support for the full experience is not as good, although using fallbacks it is possible to add at least a similar experience. However, compared to how the fallbacks are written in Option C where they could be automated in the SCSS mixin, in this case, one would have to create fallbacks more manually. One could, of course, construct some sort of automated fallbacks using SCSS again, but then it would not be mainly a CSS solution.

When to use

When you prefer using fallbacks like @supports and want to write modern code.