How to Get Started with REMs
So you’ve built an amazing project and have all your information displaying properly in the browser. Congratulations! Now comes the fun part — making sure everything is rendering properly on as many different browsers as possible by adding some CSS styling.
Obviously this means that you’re going to have to get some media break points going, and make sure that all the elements on your page are as responsive as possible — but where does one even begin to start?
A pretty good place generally is with your fonts, and more specifically, any elements you’ve previously defined using pixels. Why? Pixels can be great for straightforward single browser resolution projects, but can cause issues as they require browsers to size them down based on window size. A great fix for this issue is to switch almost all elements defined using pixels into REMs where you can.
But what is a REM?
A REM, which stands for “root element”, uses the root font size as its base unit of measurement. This is fantastic, because it means that all your elements that use REM will use whatever the browser is setting for a user’s default root font size — and going even further it means you can use percentages to define just how big a REM should be in your project so that you can keep the ratios between elements the same for all users, regardless of their default font size.
Calculating REM is easy — all you have to do is take the root font-size value, and think about it in terms of pixels. If the root font-size is 10px for example, 1 rem would be 10px. Therefore, if you wanted to have a value of 16px, all you’d have to do is set a value equal to 1.6rem. However, in most cases you actually don’t want to set your root font size in pixels, as it makes it into a static pixel value, defeating the purpose of this entire exercise to make your project as fluid as possible.
Instead, you want to set your root font-size as a percentage. This way you can control the root font size in your project while still taking into account a user’s preferences and browser or device. The standard value to set for this is 62.5%, which generally equates to 16px in a typical default browser window — but if a specific browser sets the default value to significantly greater or less than this value, you’ve now ensured that what renders is equivalent in ratio for this browser, and a ratio of 16px for everyone else.
“That’s neat”, you might be thinking, “but I’m still not convinced why should I use it.”
There’s a few reasons, but accessibility is a big one. If you’re setting all your font-sizes, elements, and spacing using pixels, you’re setting hard coded values that a user can’t change manually or based on their own unique browser properties. You’re hoping that a user zooms in and out of their browser window if they can’t see elements properly, while simultaneously hoping that everything renders normally when a user does that.
Also, just keeping in mind usability 101 and user experience basics, a user probably isn’t even going to bother doing this. They are FAR more likely to find another site or service like yours that renders like they want based on personal preferences as opposed to taking the time to give the zoom a try, meaning your lack of styling flexibility may cause your business money.
If you’re still not sold on REMs you should also note that REMs are pretty different than another possible option instead of pixels — EM. EM values are calculated using the font-size of a parent element, so everything will be adjusted by any parent that proceeds the current element you’re trying to set a value for.
If you’re nesting complicated elements in a CSS sheet, font sizing using EM values can become convoluted and render unexpectedly, whereas REM will always be relatively straightforward as they are always defined by the font-size of the root element, regardless of where the REM value is in your CSS. It also means that if a user (or you, as you work) wants to rescale everything quickly, all you have to do is change the root font size within the html element — and your whole project will shift uniformly accordingly if all relevant values are also defined in REMs.
Enough theory — let’s take a look at an example of REMs in action:
Here you can see that we set a root element using SCSS to 100% — for me this is approximately 16px, but it might look larger or smaller for some of you depending on your settings.
I’m then setting a body font-size element at 1rem, or 16px in my case, to reflect this value as a default within our <body> tags. You’ll see that the fonts in our actual render vary in size though. What’s up with that?
Well, it’s because I’ve set different REM values for app-header and app font-size classes, as well as content class’ padding. They ignore our body REM value because even though they’re technically nested within the <body> tag, they just use the root 100% value as their frame of reference because of their unique REM definitions.
Therefore, the app-header font-size is 50% larger than root, app font-size is about 25% larger than root, and content padding is actually 50% smaller. This equates to about 24px, 18px, and 8px respectively for those elements — but the beauty here is that those values aren’t static. They could be larger or smaller for users based on what their default root font-size is, because remember, we’re just taking 100% of that value— regardless of whether its 10px, 16px, or even 20px. Everything will have the same ratio ultimately, regardless of defaults.
You might also immediately notice that the content class isn’t defining font-size — good catch. Here, it is defaulting to what we’ve set within the parent <body> tag, as it defaults back up to the parent when no value is found. However, we do have a REM value for padding here that does get taken into account and used for our padding value. This is going to scale based on root font-size, because REM can stand in for most anything pixels can do — padding, spacing, margin, and more can all take REM values. This means that you can keep the entire project within the ratios of browser default font-size — pretty amazing!
REMs can provide a ton of benefits when it comes to code maintenance and flexibility/responsiveness that pixels really fall short on. Really the only time you should worry about maybe not using REM is if you’re building a site specifically for an audience that you know is using very old browsers that may not support the feature.
To be honest, this is a fraction of a percentage of overall users in 2018 — the only browser that falls short on support is IE 8 and under — but even then you can use a preprocessing compiler like SASS/SCSS to fix this if you like!