The Ultimate Ideal Bestest Base Font Size That Everyone Is Keeping a Secret, Especially Chet

In response to Andrew. Reply

Yup. Pat also pinged me on Masto, though he was just being mean. This is the challenge of a self-imposed word count.

FWIW, I tend to avoid rem because, from experience, as a unit it has confused the heck out of some devs. But %, and especially 100%, just seems to be easier for many of them to grasp.

In response to Chris LaChance. Reply

Chris, I was not aware of this, er, trick. I made a test page (debug mode for easier testing) to see if I could make it happen and yup, my iDevice scales the text with the system accessibility settings.

This is necessary to prime it (note that I do not set a size):

body {
  font: -apple-system-body;
  /* other styles, including font-family */
}

And then that novel @supports declaration:

@supports (font: -apple-system-body) and (not (-webkit-touch-callout: default)) {
  :root {
    font-size: 100%;
  }
}

In the CodePen I use some truly awful fonts to demonstrate I can still set whatever without blowing up this trick.

In response to Chris LaChance. Reply

Small note, playing around with this today. Needs font: -apple-system-body set on :root for REM to work.

In response to Mary Burk. Reply

Mary, MS Word is well outside the scope of this post. However, features of Word make it easier for people to customize an existing document:

• styles, which ensure things like headings and lists and plain text and so on are consistent and easy to make larger and smaller; and
• templates, which a user could use to quickly reformat an entire document into styles that are easier for them to read.

In response to Anonymous. Reply

[…] your website scales font sizes up by 30% for paragraph text, which isn’t that different from scaling it on the body

That selector scales it on the content container (so not the home page, not the footer, not the header, not the navigation, etc), which also includes more than paragraph text but less than all text covered by the body. Minor point, of course.

Anyway, I don’t really see the issue with setting a custom base font size so long as it’s in relative units (%, em, rem) and not pixels. That way it still scales off the user agent font size. It won’t match the user’s *exact* preferred font size, but at least it will scale proportionally.

The advice in this brief post is about starting from the user’s own preferences. Ideally authors would not set a base font size without first thinking through why they want to set it. For my site I chose to make it bigger than the user’s default because I wanted to reflect my own loudness. Some users aren’t thrilled by it, of course.

In response to Scott Kellum. Reply

No accessibility issues, no. Using html/:root is essentially the same for a new page without the burden of pre-existing styles or aggressive design systems. As the very second link in this post notes, where you choose to set it can be a function of the kind of technical debt third-party or unplanned styles will impose.

As far as I know, your approach (referencing the value with rem elsewhere) has no special effect whether you set it there or with the body selector — barring the kinds of opinionated pre-existing or post-development styles I just mentioned.

In response to Adam Page. Reply

Sure, it allows (forces) the user to adjust their default browser font size to be 160% just to restore the page to their original and preferred size.

The point of this post is to support users first, not authors.

In response to Yannick Connan. Reply

This is an amazing catch! I would definitely try that out when using custom fonts.

In response to Chris H. Reply

Hi, Chris! I refer you to the third paragraph under the Because heading. Also the 6^th and 9^th comments on the post you linked, both by the post author.

In response to lama. Reply

I think leaning on user preferences is always a good idea. “Graphically-oriented” could mean anything from charts (where you should definitely consider user defaults for visible labels) to content with lots of pics (where images themselves should probably be limited by viewport sizes anyway).

I would tend to agree that a responsive layout should account for this. Otherwise it’s not responsive, it’s relying on pre-defined values that may have no bearing on the user’s preference or settings.