Unchanging font size, leading, and measure are incompatible with dynamics of responsive design

Question

The new Responsive-Design theme doesn’t work for small viewports — nor for very large ones either!

In the new, would-be “responsive” design, the actual font size used does not vary as a function of the width of the viewport. Neither do any of the other measures that should in turn be scaled as a function of the font size, such as line-spacing or letter-spacing.

That means the same invariant font is used in headers (h1, h2, h3) used for display text, the body font used for text paragraphs, the monospaced font used for code sections, and the caption-sized text used for sidebar info, no matter what the viewport width is.

It also means that people with wide monitors have trouble using the site: there’s too much tiny text and too much dead space on the edges:

This doesn’t look good. Considering that it can easily enough be made to look much, much better, it should be. The same size text will never look right both on very small viewports as well as on very large ones. To be responsive, you have to adapt.

See Optimizing for Large-Scale Displays at CSS-Tricks.

---

In the second edition of Michael Butterick’s Practical Typography, the author writes in his appendix on Responsive Web Design the following:

The main chal­lenge, of course, is get­ting the ty­pog­ra­phy right. Early in the re­spon­sive web era, it was com­mon to see lay­outs with nav­i­ga­tion and im­ages care­fully en­gi­neered to scale up and down with the screen size. Mean­while, the body text was largely ig­nored—set at a fixed point size, and al­lowed to re­flow from edge to edge, re­gard­less of the screen width. Not good.

There­fore, for those em­bark­ing on a re­spon­sive-de­sign project, one key re­minder: the rules of good ty­pog­ra­phy don’t change with screen size.

(various practical tips omitted for brevity’s sake)

I realize that we are, to use Butterick’s word, “early” along in the Stack Exchange Network’s first foray into responsive design. But there’s no reason that we cannot or should not avoid the problems which he points out that early adopters into this technology are prone to creating for themselves and their readers. We should not ignore the body text.

To see how this “should” work under responsive design, Butterick’s website is one that reacts responsively to changes in viewport size to adjust the sizes used for headers, body, and captions, including line length. I recommend playing around with his site to see how much better it looks when it’s actually responsive.

Any of several mechanisms could be used to effect an actual responsive design in this regard. You can see Butterick’s approach in his CSS easily enough. For more examples of these techniques, along with discussion about its methodology and appeal, here are four more websites you can play with that go at all this slightly differently, but still effectively:

1. Adrian Sandu’s article Understanding and Using rem Units in CSS at the Sitepoint site.

2. Laura Franz’s article on Size Matters: Balancing Line Length And Font Size In Responsive Web Design at Smashing Magazine.

   Quick summary: As we refine our methods of responsive web design, we’ve increasingly focused on measure (another word for “line length”) and its relationship to how people read.

3. Matej Latin’s article on The Equilateral Triangle of a Perfect Paragraph over at the CSS Tricks website.

   The recommended size for today's screens is 16px for mobile and from 18 to 22px for desktop. This also depends on the typeface. Some typefaces set at 16px may seem larger than others....

   The ideal length of a line of text is from 45 to 75 characters—including spaces. Anything that reaches far from that range becomes hard to read.

4. Oliver Reichenstein’s article on Reactions to 95% Typography over at IA.net, which in turn is the follow up to his earlier piece on The Web Is All About Typography, Period, which he’s since renamed.

   Typography in practice is not choosing fonts or making fonts, it’s about shaping text for optimal user experience.

   Where usability gurus usually fail:

   1. The text lines (measure) are too long.

   [...]

   5. Linespacing is too narrow

Besides reading what the five sites I’ve referenced say about this in print, it’s also worth digging into the CSS and yes even 𝒿𝒬𝓊𝑒𝓇𝓎 that they’re using to work this elegant magic.

This is what you see under responsive design on professional sites that care about the readability of their text: they also scale their fonts, not just their images.

But there’s a great deal more to it than just that.

---

Wrong line-spacing for Serif paragraphs

The articles by Matej Latin and by Oliver Reichenstein are especially important to this discussion. They not only carefully explain why you need to adjust all three sizes to fit the text, they also provide illustrations of how bad things are when you haven’t done so. (Hint: the whole thrust of this post is that you have not done so, so please read those.)

Stack Exchange is currently ignoring the measure altogether in setting the font size, and it is also blindly setting the line spacing to 1.3 no matter whether what the measure is, no matter whether you’re in a sans-serif face or a sans face, no matter whether you’re in a header or body or caption, and no matter whether you’re on Windows or a Mac. All these things and more matter a lot, and they’re all being completely ignored. We can do better. Please.

The fonts you’re choosing here have very different aspect ratios, and yet you are setting their line spacing to the same 1.3 factor. Crazy! That’s another source of error. Arial’s aspect ratio is 0.519, while Georgia’s is 0.481. And for the sites that don’t have Georgia, Times New Roman’s aspect ratio is 0.448. You wouldn’t want to set those three the same even if they were the same class of serif vs sans-serif vs mono. And they aren’t even that. Plus Times is a darker face than Georgia is, so you have to take that into account, too.

Platform Problems

TLDR: You’re treating Windows and Macs the same way, and this is a big problem.

Courtesy of VMWare, here’s a real-world side-by-side illustration of both platforms next to each others. This shows you how very ugly this makes our text paragraphs, with Windows on the left and Mac on the right, for this post:

In both cases, the measure is the same, and the line spacing is set to its bog-standard 1.3. That does not suit such a long measure set in Georgia. You’re using 16/19.5 when you should be using at least 16/22.4 (so line-spacing 1.4) and maybe 16/24 (so line-spacing 1.5) for the serif paragraphs. You should not be using the same line spacing for a serif face with a wide measure as you are using for a sans face with a narrow measure. But you are. That 1.3 value only works for the super teensy-tiny sans captions with the short measures over on the right; it doesn't work for body text in Georgia here, especially with these too-long measures.

Please notice how super-awful it looks on a Mac. The tiny paragraphs are set much too tight. And they’re very dark, too. Beyond not setting the measure or line spacing right, there are two more reasons why the Mac looks so awful. You aren’t adjusting the font size based on the platform. You need to scale up the font size by 150% for Macs to make it look the same as on Windows. Well, or scale the Windows sizes down to 67%. The first point is that they are much too tiny on a Mac; so is everything. (I don’t know why it’s a 3:2 factor not a 4:3 one, but it is.)

Notice how Butterick does this for his site: he compensates for Windows-vs-Mac by serving up the same pages by scaling up the font size when serving Mac requests compared with Windows ones.

But even when you equalize the sizes, they still aren’t the same:

1. Chrome of same page; Windows on left and Mac on right, but Windows zoomed 67% to match Mac:
   

2. Chrome of same page; Windows on left and Mac on right, but Mac zoomed 150% to match Windows:
   

Either way you equalize it, you can see what’s happening: the text on the right is much darker than the text on the left. It’s much too cramped this way. The renderer on a Mac is creating a much darker rendition of Georgia than the one on Windows is for exactly the same size and exactly the same font. And darker fonts always need more space for a balanced paragraph, as the Matej Latin article points out.

I don’t expect you to be as clever as Butterick is and serve up a version of the font that’s a little bit heavier on Windows than the version he serves up for Macs (even though you should :). But you definitely need to take the darker fonts into consideration when setting the measure and line-spacing for the Mac paragraphs. Otherwise it won’t look like a balanced paragraph. (It already isn’t due to the too-long measure and meagre 1.3 line spacing that doesn’t work here, but this is something else to think about.)

Because you haven’t done any of these things, the serif paragraphs look quite bad, especially on a Mac. It’s also why the bold is much too bold on serif sites, but you aren’t going to fix that when you’re stuck with system fonts from the 1990s that come in only two weights, 400 and 700.

A Gentle Supplication

I know you guys are a 100% Microsoft shop through and through, but please please give your web designers some Macs so they can see what they’re doing to the rest of us. It matters. For example, any text rendered light-on-dark is being automatically bolded and blurred on a Mac. Here’s a side-by-side demo of what this ends up looking like, this time with the Mac version to the left and the Windows version to the right, zoomed to equalize sizes. This shows how bold and muddy the webkit smoothing is on the Mac using your default setting of auto here:

To fix this, you probably need these bits of CSS for Macs:

-webkit-font-smoothing: antialiased;
-moz-osx-font-smoothing: grayscale;

The only place the new responsive design looks good, especially for serif sites, is on a little cell phone in vertical orientation. Please make it work for desktops, too. Responsive design is not just supposed to look good only on mobile devices. If it does, this wastes the chance to do a good job.

---

One last matter, one that probably deserves its own post.

You seem committed to the one-font-to-rule-them-all approach for titling text versus body text versus caption text, and to using nothing but primitive system fonts from the 1990s. :sad-panda:

Under our current technology, no font is ever going to have the right metrics for all possible display sizes. Although some families like Arno do come in multiple fonts each with metrics for different optical sizes, no system font does. And browsers won’t know to flip between versions “cut” for different sizes based on the point size. The tech just isn’t there yet.

Because you seem committed to using a given system font at all possible sizes, the very least you should do to ameliorate the resulting problems is to adjust the letter-spacing and line-spacing accordingly.

Otherwise you get gaping holes in the giant header text, etc etc. Sites that care about typography do this, and as we know, “webdesign is 95% typography”. :)