How to use REM for Responsive Development

Table of Contents

Using Breakpoints for Responsive REM Architecture

Alright, so we understand now how we can keep the ratio of our designs consistent by setting our starting font-size, and then having styles like padding, margin, etc all relevant to the content inside the component. That’s great, but how do we make our entire application responsive using REM units?

Well, the key to that lies in setting “Breakpoints” intelligently. Before we dive into why we said ‘intelligently’, let’s define what a breakpoint is and how they are typically used:

A “Breakpoint” is a way to specify which CSS/SASS logic will be used for predetermined screen sizes. Once the screen-size (breakpoint) is hit, the styles under that breakpoint will take effect.

Breakpoints were created to provide easy to understand ways to adapt CSS to different device sizes, and if you’re wondering the answer is yes, they work! However, while breakpoints can create responsive layouts they come with some serious drawbacks:

Breakpoints are not fully responsive – they rely on ‘ranges’ so you’re dealing with averages.
Breakpoints require code duplication (i.e., in the example below we declare mission-content twice)
Additional device sizes require additional breakpoints. (imagine a new phone size is added)
Breakpoints require more code, and more code equates to more maintenance.

As an example, let’s look at the following code snippet for a single component:

In this example we have the following issues: 

  1. Padding is fixed at 20px, which means it does not act responsively from 1-766 pixels.  On a much smaller layout, the padding would likely appear too large.
  2. ‘Mission-content’ is declared twice, which breaks the rule of avoiding code duplication.
  3. For additional screen sizes, we have to declare additional breakpoints and additional code duplication which makes maintenance a nightmare. 
  4. This requires multiple breakpoints on every responsive component.  That’s a lot of code!

So if you are building an app with 100 components, you’ll likely need to have 100 ‘.scss’ files that EACH have their own breakpoints using this approach.  That is a lot of duplicated code, and a lot of overkill!   Is there a simpler way?   Yes, most definitely 🙂 

The simple answer is that we still need breakpoints; but if we use a REM focused architecture we can set our breakpoints only in one place – the root level.

html {
   /* If we change this using a responsive REM approach, it will modify the starting sizes of all implementations that use rem in our application */
   font-size: 16px; // most browsers default to 16px;
}
 
/* Extra small devices (phones, 600px and down) */
@media only screen and (max-width: 600px) {
 html {
   font-size: 14px;
 }
}

In this example, we can see that as the device size increases and decreases we are changing what our html font-size is.  This has a cascading effect on all the components that rely on REM; and if we setup all our components to maintain their ratio to the font-size then we’ll see a fully responsive layout. 

They will not scale to multiple device sizes, as can be seen very easily in this gif by designer Sandijs Ruluks.

Designer Sandijs Ruluks explained responsive web design easily with gifs on his blog.
Designer Sandijs Ruluks explained responsive web design easily with gifs on his blog.

With REM however, you can instead set only a single set of breakpoints at the root level, and then from that root level have everything else respond accordingly.

Additional Mobile App Guides
Connect with us

Are you enjoying our guides? Share your thoughts and let us know what you would like us to write about next!