Avisto

Posted on Jun 9 • Originally published at Medium on Apr 29

CSS Units: What Are the Real Benefits?

#webdev #css #cleancode

In the previous article, we reviewed the list of CSS units and their particularities. But beyond the theory, one question remains: what are the real benefits? Why complicate your life with px, em, or percentages, when you could simply use rem across the board?

❔ Reason #1: Representing Reality as Accurately as Possible

Potentially the most obvious, yet also the hardest to observe: the work of web developers cannot be reduced to frantically writing lines of code. It’s primarily about describing a reality using a language. Every line of code represents a behaviour of our interface — put differently, every property used, especially in CSS, describes an aspect of that reality.

Here’s an example to illustrate the point. It will serve as our running thread throughout this article.

Below, two buttons:

A *blue * one,
A *pink * one.

Set aside their colour difference — they are the same button. Yet, screen size aside, here is how their sizing is expressed:

Blue button has a height of 48px and lateral padding of 16px

Pink button has a height and width of 100% of its parent

→ Same result, yet the intentions are very different. For fun, let’s add another implementation:

Want to try and guess this one? Here’s what we get:

Green button has a height and width adjusted to its content, with padding of 1rem

This small demonstration illustrates well why so many units exist. They allow a need to be expressed in different ways:

The blue button works for a simple design, when there’s no need to reuse it or place it in a complex layout.
The green button represents an attempt to handle font size changes.
The pink button is designed to be used in grids or flex containers (grid or flexbox), because it’s the layout that will determine its final size.

On a standard mockup, these three buttons will look identical. If their size varies from page to page, the mockup will simply indicate that the size has changed — without explaining why.

🧙‍♂️ The key takeaway: the choice of units should not be driven by technical considerations alone, but also by design and product decisions.

❔ Reason #2: Building Truly Responsive Interfaces

Is there a direct gain from using font-relative units when building a responsive and robust interface? → FALSE

The most common misconceptions that fuel this belief:

The strong resonance between the words “responsive” and “relative.”
The “dynamic” side: a “dynamic unit” that might suggest it’s useful for building “dynamic pages.”
The fact that “relative” evokes adaptability, and therefore responsiveness.

The mistake is both semantic and technical: a proportional unit is often confused with an adaptive layout capability.

Many more could be imagined, but this shows how fertile the ground is for well-meaning but misguided ideas.

It’s important to keep in mind that the responsiveness of a page plays out primarily at the level of what we call the layout [7] — that is, the space allocated to each element on a page. A responsive interface is one that has adaptive layouts.

Illustration of adaptive layout principles

Here’s an example with a “classic” interface displayed on a desktop screen:

Big layout — Desktop resolution

On a tablet, the layout changes and the presentation of elements is no longer the same. It’s not just a matter of scaling things down:

Medium layout — Tablet resolution[9]

It’s even more striking on a mobile interface:

Small layout — Mobile resolution

What happens when you reduce the browser window size? Is the text size reduced? Are the gaps between cards smaller? Is the overall look preserved?

As you’ve gathered, adaptive layout is designed to maximise the quality of the user experience on every device. As a result:

The layout and its components will be reorganised.
The card arrangement will change, and the navigation bar will be replaced by a “burger menu,” better suited to smartphones and tablets.

This is not simply about “shrinking everything.” To create an adaptive layout, we use breakpoints :

These are customisable widths that determine how our layout behaves based on the width of the device or window [11].
Most libraries provide reference values (such as sm, md, lg, etc.) [14].

⚠️ A word of advice: never reduce text size just to save space! Yes, on mobile, font size can afford to be slightly smaller because the distance between screen and eye is shorter. But that choice should never be motivated by saving space.

🧙‍♂️ To sum up: using relative units does not mean you’re building a responsive interface. For a truly responsive design, the real challenge lies at the layout level.

❔ Reason #3: Managing Accessibility

This is an essential issue that, despite its importance, is often poorly understood when it comes to units — largely for historical reasons.

Before 2005, browsers were technically limited: when zooming, they were unable to scale font sizes along with the rest of the page content. This meant that at the time, the only way to enlarge text on a screen was to change the font size at the device level. That size would then be used as the default for all web pages visited.

We won’t go into the detail of the “C” in CSS here, so we’ll use the term “default font size” rather than “root.”

So, before 2005, the only way to make your site accessible to visually impaired users was to use rem — the unit relative to the default font size. Your application's font-size values would then scale based on the user's choice.

Today, browsers have evolved significantly and handle font scaling very well, even with absolute units during pinch-to-zoom.

a “pinch-to-zoom”

⚠️ Pinch-to-zoom can help in a pinch, but it doesn’t replace proper text size management. Some users only adjust their font size settings — so you need to account for them to ensure full accessibility.

Now, suppose we’ve expressed all our text in rem and the following statement seems correct to us:

The text in my application is a multiple of the default font size

Let’s observe the behaviour on our buttons:

All 3 buttons have a font-size of 1.2rem. If the user hasn't changed their font size, that equals 1.2 * 16px = 19.2px.

We can already see that the green button takes up more space than its neighbours, and the label on the pink button is dangerously close to the edge of its container.

Now let’s change the browser font size to observe the impact on our buttons. In Google Chrome:

Settings > Appearance > Font size

Below, our 3 buttons with a “very large” font size:

Font size “Big”

Below, our 3 buttons with a “very small” font size

Font size “Small”

The green button handles it better than the others! it’s not perfect, but the proportions are respected. The reason is simple: it’s the only one using rem for both text size and spacing.

Be careful though, it’s not magic. Relying on rem to handle default font size changes can quickly become a slippery slope, even a swamp.

If the green button were contained in a layout whose dimensions couldn’t accommodate a larger component, the interface would have broken.
Conversely, if the buttons had pixel-based dimensions, this problem wouldn’t arise — their size wouldn’t depend on the font size at all.

To successfully combine responsiveness and font-size accessibility principles, careful design is required one that involves the whole team, not just designers. It’s also a question of budget, whether that means team size or available resources.

❔ Reason #4: Keeping Calculations Simple

You may be starting to sense a certain critique of em and rem. You'd be right they very often increase the already considerable complexity of CSS.

If your site doesn’t benefit from a design that accounts for font size changes via system settings, then there’s no reason to write your values as multiples of 16.

In reality, beyond the “drawing” aspect, there’s another reason people dislike CSS: its readability complexity.

It’s very easy to accidentally override a property without realising it. The cascade feature is a double-edged sword. CSS is also sometimes written in one file and applied somewhere entirely different in the application. This is a complexity that brings no pleasure or merit whatsoever.

Honestly, reading CSS is like untangling a big ball of knots! It’s long, complicated, and not particularly stimulating.

This largely explains the popularity of utility-first CSS with Tailwind.

So this is really not the place to add complexity without good reason. Look at this example :

Right outer margin measures 2.3rem and my border is 0.2rem thick.

In that case, you focus purely on the result and hope there are no bugs because frankly, no one understands what was written. You end up with “dead” code that nobody dares modify or delete, because nobody knows concretely what it does. On projects that live for several years, this inevitably leads to a full rewrite at some point.

Moreover, on a project with no deliberate thinking on the subject, you’ll find nested rem and em values with font sizes changing in ways nobody planned. Add breakpoint management on top of that, and nobody is able to predict the size of elements displayed on screen anymore.

As you’ve gathered, knowing the units is good, but knowing how to choose them correctly is a whole other mission.

The next article will no longer be about units. You’ve got those down now. Instead, we’ll look at the minimum CSS architecture needed for real-world projects.