To em or not to em? That is the media query question.

There’s a lot of debate on whether to use em or px for breakpoint units in media queries. A few years ago Luke Wroblewski demoed his site at An Event Apart using em breakpoints. When he increased the browser’s font size, the page morphed into a layout that better accommodated the larger text. The audience oohhed and ahhed, and I was sold on em-based breakpoints.

In Luke’s demo the page actually switched to its mobile design. If the breakpoints had been pixel based, the layout would not have changed to its mobile design. However, the text size, which was defined with a responsive font-size unit, still would have increased. This could have resulted in cramped text if he had used pixels for size, margins, and padding values.

Recently I wondered about the applicability of em-based breakpoints — are they the right solution for all designs? Are there any disadvantages? To answer these questions for my day-to-day work I needed to understand the mechanics of em-based breakpoints as well as the direct visual impacts they have. So I dug deeper into the topic with my own testing. After the investigations, I was most intrigued by the fact that a browser’s font size setting affects the calculated value of an em breakpoint.

em- vs. pixel-based breakpoints

Below is an example in which .banner (let’s assume it’s a div) is full width by default then gets a fixed width on viewports at least 1024 pixels wide. (Please note that all code snippets here are written in SCSS syntax.)

.banner {
    font-size: 1em; // 16px
    padding: 16px;
    @media (min-width: 1024px) {
        margin-left: auto;
        margin-right: auto;
        width: 900px;
    }
}

Now look at this similar example with an em breakpoint:

.banner {
    font-size: 1em;
    padding: 16px;
    @media (min-width: 64em) {
        margin-left: auto;
        margin-right: auto;
        width: 900px;
    }
}

We’ll assume the browser’s default font size is 16px. (This is the case for most of them.) Just like the first example this media query will kick in at 1024-wide viewports (16px * 64em), but if a user increases his default font size in the browser settings, the calculated breakpoint value will also increase. For example, if the user changes the font size to 24px, the breakpoint will be 1536px. What this means is that the media query styles won’t apply in viewports under 1536 pixels wide. In this scenario someone on a tablet or laptop might see the mobile layout if the newly calculated breakpoint value is larger than his viewport width.

This might be desirable because when text size is increased, it sometimes needs larger containers to gracefully flow on the page. Since mobile layouts are often designed more simply, sometimes in a full-width stacked layout, this would give text more horizontal space.

What if you don’t want mobile layouts on large screens?

So what if you find that your mobile layout isn’t optimal on desktop screens? Consider the following mobile design:

Let’s say we want the white boxes to appear in a single row on screens at least 1024 pixels wide:

Here’s the initial code for this example using an em-based breakpoint:

.product-item {
    font-size: 1em;
    padding: 16px;
    @media (min-width: 64em) {
        width: 272px;
        .product-list & {
            display: flex;
            justify-content: center;
         }
     }
}

Let’s say a user has a laptop with a screen width of 1440 pixels, and he’s using Chrome. With the em-based media query if he increased the font size to 24px, the page would look like this:

The page displays the mobile styles because the calculated breakpoint is now 1536px, and the user’s screen maxes out at 1440. This doesn’t look terrible, but there’s now a lot of empty space in the white boxes because each is full width. There are two techniques you can try in tandem to achieve balance in a responsive desktop layout:

• using px units for your breakpoints
• using responsive units for element widths and spacing

Let’s first convert the breakpoint to pixel units. With this change the following are true when the user increases his browser’s font size:

• The padding stays at 16px.
• The banner’s width stays at 272px.
• The calculated breakpoint value remains the same.

You can view a live demo on CodePen and try out the media queries. Below is a screenshot with the results so far.

As you can see, because the product-item's width doesn’t change, any text will potentially look cramped as its size is increased. Let’s now convert the padding and width to em units:

.product-item {
    font-size: 1em;
    padding: 1em;
    @media (min-width: 1024px) {
        width: 17em; // 272px / 16px * 1em
        .product-list & {
            display: flex;
            justify-content: center;
         }
    }
}

The padding and width will scale up as the font-size increases. The text looks more comfortable within each box.

So is that the solution?

No, not necessarily. The hybrid responsive layout is not the smoking gun solution for everything. In Chrome a user can set the font size as high as 72px or even larger if he uses a third-party CSS extension. Below is a screenshot of our demo set to 72px with the hybrid responsive layout. I only included a portion of the page since it was very, very tall.

Pretty terrible. In the end the purpose of this investigation is to understand how em-based breakpoints affect layout. For me the key lessons and considerations are:

• Test your layouts in a range of font sizes.
• Determine if your mobile layout on bigger screens degrades the user experience.
• If it does and you try a hybrid responsive approach, how does the layout stand up to very large font sizes? Does it still provide a decent experience?

In my opinion most page layouts are complex enough that it’s best to be safe and use em breakpoints in your media queries in addition to responsive units for font sizes, dimensions, margins, and padding. This decision is ultimately an individual one, but be sure to test and consider your audience.