REM vs. EM – The Great Debate

I use REM for pretty much everything but still fall back to px for padding and margins which hasn't been a problem for me so far although I can see why selective use of EM could actually be useful.

Tangentially related. It bothers me a lot that we have to add classes like header--large onto a component. The classname header--large should be able to automatically switch depending on it's parent containers size (and not the window size like media queries work). My component may be presented it 3 different styles depending on the size constraints of it's container and hard-coding --large into the classname just makes it a hack. It's not large on mobile so why am I overriding the styles of my desktop header--large classname.

Ideal situation, parent container media queries so that variations can be kept solely in css and you could just drop a component into anywhere. I'm guessing there are some circular dependency issues stopping this from working maybe?

I utterly loathe using em units. Rem is better, but px are nice and locked down. Em's are neat in theory, but reasoning about them after the CSS has solidified is so tedious.

Em units begin to feel like a weather app telling you today's forecast as a multiplier of yesterday's temperature.

Today is going to be 1.1!

[uninstall]

Since obsolete unterbrowser users must suffer, rem FTW.

What's REALLY missing in modern CSS3 standard is the ability to reassign CSS root to any other element than <html>, according to font properties of which all nested rems would be calculated. So, for now, we have to stick to assigning base font sizes to <html>, not even to <body>.

My microframework (999.css - http://999.surge.sh) uses pixels to assign base font size to <html>, rem for <body>, ems for headings and rems for all other nested typography.

The main issue I have with either of them, is sometimes having to resort to using crazy values like 15.974rem or 2.0736rem (taken directly from the author's website). Using pixels shouldn't be frowned upon, considering all the preprocessors available, and how CSS variables (the next big thing) are around the corner.

But I would always use EMs for any WYSIWYG generated value, where the design solely relies on HTML tags, not CSS classes. It's then easy to alter the container's font-size while maintaining consistency and balance between all its children.

For borders, in any case, it's better to stick with pixels. Some people started writing things like "border: 0.065rem solid #ccc", which would make the border disappear if you either zoomed out, or set the font-size to something smaller than 16px.

Can someone explain to me why I would want to use either over px? I just don't get it.

"One of the best practices to typography on the web is to use relative units like rem and em.", it says, but why?? I get as a general philosophy that relative might be preferable over absolute, the way you prefer relative paths in your build system. But "relative" in this case means relative to the font size which is either specified or the default, both which makes s using absolute values just as valid and easier to comprehend..?

In my experience most projects that need to worry about things like this are too big for a high level of consistency to work. Either that, or the design is sacrificed to make the code easier. Whenever a designer looks at a page they say "left a bit, down a bit" until they're happy with it, regardless of consistency.

So, yeah, use rems or ems if it makes your life easier. Use a CSS preprocessor with lots of helpful variable names and functions. And just don't worry about it.

I got kind of excited at the prospects of a study seeing how EM radiation affects our REM sleep patterns, eapecially with the degree the IoT and 5G will envelop us in the very near future. Unfortunately that debate will be another day...

What about good old px? I recently came across this article [0] which argues that after all the "best practices" of rem vs em maybe px is actually the best way to go, in order to accommodate high density displays and zooming.

[0] https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva...

For me, both units are pretty useless. PX is the way to go except for some cases, e.g. a button's padding that scales with its text or baseline grids. The following article (not mine) explains why pixel win: https://mindtheshift.wordpress.com/2015/04/02/r-i-p-rem-viva...

In Semantic UI we include two distinct header types that sized using either REM or EM. Page headings which are generally consistent across a site and usually specified with H1-H5, are sized using REMs so they display consistently. Sizing variations, (tiny, small, large, huge etc) however use EM to allow them to be sized relative to its content container.

If you do the following:

  html {
    font-size: 62.5%;
  }

You can convert from pixels to rems (or ems) quite easily:

  p {
    font-size: 1.4rem; // 14px
  }

I use rems for stuff that needs to scale with text, ems for line-height and pixels for everything else.

I rarely use rem since I only stopped needing to support IE8 recently. Instead, to deal with the pain of em calculations I use these sass mixins (feel free to use; license CC0 https://wiki.creativecommons.org/wiki/CC0) (below is my first attempt at "sassdoc," which I happened to discover while preparing this comment):

    $current-font-size: 16;
    
    // Remove the units from a value (pretty sure someone else wrote this originally)
    @function strip-units($number) {
        @if unit($number) == '' {
            @return $number;
        }
        @return $number / ($number * 0 + 1);
    }
    
    /// Sets font-size and line-height using percentage and unitless values respectively, with support for nesting.
    /// @param {Number} $new-font-size - Desired new font size in pixels (units ignored)
    /// @param {Number} $new-line-height - New line height in pixels (units ignored)
    /// @param {Number} $context-font-size - Current font size where you're including this mixin, if it isn't the global $current-font-size
    @mixin font-scale($new-font-size, $new-line-height:null, $context-font-size:$current-font-size) {

        // Set the font size
        $context-font-size: strip-units($context-font-size);
        $new-font-size: strip-units($new-font-size);
        $font-ratio: $new-font-size / $context-font-size;
    
        font-size:$font-ratio * 100%;
    
        // Set the line height
        @if $new-line-height != null {
            $new-line-height: strip-units($new-line-height);
            // Honestly don't remember why the "+ 0.0001" here:
            $line-ratio: $new-line-height / $new-font-size + 0.0001;

            line-height:$line-ratio;
        }
    
        // Include nested content with global $current-font-size set to the new value
        $last-cfs: $current-font-size;
        $current-font-size: $new-font-size !global;
    
        @content;
    
        // Reset the global $current-font-size to what it was before
        $current-font-size: $last-cfs !global;
    }
    
    /// Convert a pixel length to ems at the current (or given) font size
    /// @param {Number} $px-length - Length in pixels (units ignored)
    /// @param {Number} $font-size - Current font size in px, if it isn't the global $current-font-size (units ignored)
    @function ems($px-length, $font-size:$current-font-size) {
        $px-length: strip-units($px-length);
        $font-size: strip-units($font-size);
        @return ($px-length / $font-size)*1em;
    }

(Those are modified slightly and haven't been tested in this exact form.) This lets me do, for example:

    .title {
        
        // Make the text in .title 112.5% (18 ÷ 16) with a line-height of 1.22 (22 ÷ 18)
        @include font-scale(18, 22) {

            // Give it 15 pixels of padding using em units
            padding:ems(15);
            
            // Make the text of a .subtitle inside a .title 14px (112.5% × (14 ÷ 18) = 87.5%)
            // (line-height remains 1.22 in this case, working out to 17.11px)
            .subtitle {
                @include font-scale(14);
                
                // Give .subtitle 5 pixels of padding, but instead of nesting
                // the mixin again, I'll just tell ems() that the current
                // font size is 14 directly.
                padding:ems(5, 14);
            }
            
        }
    }

The nesting isn't attractive and `ems(15)` is a little more typing than `15em` (though not more than `(15/18)×1em`), but I think just using em for everything reduces some cognitive load.

It also lets you do some tricks, like you can set the root element of some component to `font-size:(16/1024)*100vw` and it'll have a "normal" size when the viewport is 1024px wide but scale up smoothly in every dimension when the viewport is larger (and down when smaller). And you can still scale the whole page, including that component, by changing the font-size of html/body.

Thus far I only use rem when I need to override something for an inner element, like if a piece of the aforementioned vw-sized component gets too small when the viewport is less than 640, I would set the font-size for just that piece in a media query using rem, allowing the rest of the component to continue to scale down.

This blog has 3 FOUTs - first - the default fonts appear, next - all fonts disappear and after this everything appears as it was at the first time and only after it the correct fonts are loaded.

REM was easier for me to keep track of and understand. But it didn't work for media/printer queries.