Font-Sizing: An Overview of px, Em's, & Rem's

28 Aug 2015 | Jordan Barber

Until now, we have been using pixels for sizing fonts. This is not necessarily a bad thing. Some of the most popular and heaviest-traffic sites in the world currently use pixels when sizing their typography (Bootstrap did not move away from pixels until the release of Bootstrap 4 only a little more than a week ago).

But there are more modern, responsive approaches to web typography, namely the Em and Rem units. The most significant difference between pixels and Ems/Rems is that the latter are relative, while the former is not. These relative units are nothing new (the first article on Ems was published in 2004).

This post summarizes these three approaches, pointing out their ups and downs and when is best to use which approach.

Pixels

Pixels are a safe, fixed unit of measure. They are straightforward and exact. Unfortunately, simplicity and precision are the only useful aspects of pixels (well, that and browser support). The downsides of pixels are that they are non-responsive and lack accessibilty. Because pixels are not a relative unit, they cause much more work in responsive web design. Below is a basic set up of how we would handle responsive typography with pixels inside of our SMACCS ‘states’ environment (this sample assumes a 1:1.25 increment ratio in font-size).

html { font-size: 16px; 
	@include bp(large-screens){font-size: 20px}
}

h1 { font-size: 33px; 
	@include bp(large-screens){font-size: 41px}
}

h2 { font-size: 28px; 
	@include bp(large-screens){font-size: 35px}
}

h3 { font-size: 23px; 
	@include bp(large-screens){font-size: 29px}
}

h4 { font-size: 19px; 
	@include bp(large-screens){font-size: 24px}
}

.small-font { font-size: 13px; 
	@include bp(large-screens){font-size: 17px}
}

As displayed above, we must currently override each pixel declaration for every breakpoint (the above only shows the large-screen breakpoint, but in most cases there would be at least 3 more of these). We will touch further on how the relative nature of Ems and Rems can save time and stress for the Front-End Developer later in the post.

Pixels also have problems with accessibility. Directly from the Treehouse video on typography, “When font-sizes are set in pixels, users cannot increase or decrease the text-size on a page through the browser preferences.” Therefore, the use of pixels does not allow users with visual impairments to alter font-sizes to their needs. Because we are moving towards making our websites more accessible, this furthers our need to move to a more modern approach.

Let’s take a look at how Em’s can eliminate massive amounts of code

Em's

Ems are relative to their parent’s base size. 1 Em is equal to the current-font size. If a parent is not set, then 1 Em is equal to the standard browser font-size of 16px. But wait, if Ems are converted to px units, then why take the extra step? Because Ems and Rems are to pixels what Sass is to CSS, basically a preprocessor. Using relative fonts will save the developer time and many lines of code while also allowing for a more fluid responsive typography system. Below is an example of how the previous pixel media queries would look with an Em approach.

html { font-size: 1em; 
	@include bp(large-screens){font-size: 1.25em}
}

h1 { font-size: 2.074em; }

h2 { font-size: 1.728em; }

h3 { font-size: 1.44em; }

h4 { font-size: 1.2em; }

.small-font { font-size: .833em; }

First off, don’t worry about the precise/offbeat values. There are great resources and tools such as this one and this one that provide Em scales and increment ratios. As you can see in the example above, we have eliminated 6 lines of code. But let’s do some calculation to see what we’re really saving. The above technique (thanks, Ben!) is a clean Sassy way of writing media queries. The @include bp(large-screens) results in an actual 3 lines of CSS. So we’re up to 18 lines of code eliminated from our CSS file. But what about the fact that we always have, at a minimum, 2 font families. We’ve saved 36 lines of code. What about the fact that we have, at a minimum 5 breakpoints (usually more). We’ve saved about 150 lines of final CSS code. Equally important, we saved the developer tons of time.

Aside from the fact that the Em technique saves time and file size, it also allows for a more uniform scale for our typography. This should be well-thought out in the design/UI/UX phase with help from this awesome tool. This is just another example of how performance is just as much the designer’s job as it is the developers (later article to come on this topic!) Now, of course there will be times when we don’t want our typography to scale exactly the same at different breakpoints, so there will still be need for overriding in these cases.

So let’s look at the one downside of this technique known as “compounding Em’s”. Because Em’s are relative to their container, nested elements compound on top of eachother. For example, an li within an li within a ul within an h4 (you get the picture), would end up being super tiny. In steps the Rem’s…

Rems

Rem’s (Roote Em’s) are relative to the root size set on the html (or 16px if no value is set). Rem’s are supported in IE9 and up, so we can use them for all of our new sites. If we need to support IE8, we can easily set pixel fall-backs. Because Rem’s are relative to the root, they avoid the compounding issue that Em’s run into.

Summary

Pixels are fixed, simple, and easy to use, but lack accessibilty and are non-responsive
Ems and Rems are relative, responsive, and accessible
Ems can run into issues with compounding
There are tons of awesome tools to optimize relative font-sizing techniques
If "Coumpound Ems" becomes an issue, Rems can save the day

Questions to consider/discuss

Is there any reason to continue using pixels? Will using a uniform approach to typography make sense with the way we design sites. If not, then the overrides within the relative technique might not save that much time or code. Need to have a meeting between design/dev to discuss.
When to use Ems over Rems? I would like to also discuss this in the next meeting. Chris Coyier points out an interesting approach here. Check out the 'conclusion' section of Jeremy Church's article.