Reading Time: 5 minutes

Having a propensity to be pedantic, today I finally reached a small breaking point with line-height. In the grand scheme of communicating design requirements, this is a tiny little thing. But, a good understanding of line-height can improve design, documentation, and code quality all at once. If you’re not using a unitless line-height right now, I’d like to encourage you to consider it because of the benefits to the browser and your team.

Wait, what is line-height again?

If you’re a designer, or otherwise a dabbler of Illustrator/Photoshop , line-height is not a setting in your UI. Typographers would call this leading. Leading is the vertical spacing between lines of text. In CSS, we control the vertical space between lines of text with the line-height property.

line-height‘s Values

line-height is like most CSS properties in that it can accept absolute or relative values. Many web projects apply a line-height with either absolute or relative values.

Some absolute units

You have your typical px, pt (1/72 of an inch, for you ‘mericans), cm (for you Europeans), or mm (for you pedants). What you type is what you get on the screen or on the paper. We tell the browser,

1. The font-size is [amount] — end of story.
2. The line-height is [amount] — end of story.
3. Make sure all children inherit a [amount of line-height]— end of story

article {
font-size: 20px;
line-height: 25px;
}

The relative units

Pixels and points are true absolute values; there is no additional computation done by the browser. But, for any number of good reasons, we may choose to employ the relative units of measurement.

The most common relative unit of measurement is the em. But, regardless of em, or %, We tell the browser:

1. Compute the font-size based on [amount] that is inherited
2. Compute the line-height based on [computed font-size].
3. Make sure all children inherit a [computed amount of line-height]

html {font-size: 10px}
article {
font-size: 2em; //computed 20px
line-height: 1.25em; // computed 25px
}

There is a lesser-known, but totally typographically true ex that counts as a relative unit of measurement. Use at your own risk.

The unitless value

While your choices are usually relative or absolute units of measurement for a given property, line-height is an exception. For it, we can provide a unitless value:

html {font-size: 10px}
article {
font-size: 2em;
line-height: 1.25; //  computes to (font-size * line-height)
}

When we use it, there’s just two steps:

1. Compute font-size
2. Compute line-height

That missing step is really important: The computed line-height is not inherited. Instead, the browser recalculates the line-height every time font-size changes for any descendant elements.

The Trouble with (Web) Typography

It’s very hard for us to understand the ramifications of an inherited vs computed line-height value. I can say it, but we really need to see it in action.

So let’s pretend a design agency has told us that articles should always have a line-height of 1.5em. Let’s get to coding:

A fixed line-height has a good start

html {font-size: 10px}
article {
font-size: 2em //computed 20px
line-height: 1.5em; //computed 30px
}

Line-height is computed at 30px. Now let’s assume some markup:

Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec lacinia ac metus vel dapibus. Quisque pellentesque egestas malesuada. Mauris purus nulla, cursus tempor purus nec, sodales faucibus sem.

And look what we get:

Seems a bit spacey, but fine. You did what the design agency asked.

A fixed line-height goes awry

Look at what happens, though, when you crank up the font-size of something inside of your article:

article h2 {
font-size: 2em // computes to 40px
}

And, again, the markup stays relatively the same:

Introducing Lorem Ipsum
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Donec lacinia ac metus vel dapibus. Quisque pellentesque egestas malesuada. Mauris purus nulla, cursus tempor purus nec, sodales faucibus sem.

Why so ugly?

That was the result of a computed line-height that was inherited. We cranked up the font-size, but didn’t change the line-height. So we have an h2 with a line-height of 30px, when it has a font-size of 40px. Now, we could fix the problem with:

article h2 {
font-size: 2em;
line-height: 1.5em;
}

Alas, this is a fix and not a solution. . We are wiser to just use a unitless line-height:

article {
html {font-size: 10px}
article {
font-size: 2em //computed 20px
line-height: 1.5; //recomputes as necessary
}

Doing so will yield a result where everything has a line-height that is proportionate and relative to its own font-size.

What we see from this is that a unitless line-height actually saves us additional lines of code, and does a perfectly good job of keeping proportions the same.

How to make the case for a unitless line-height

There’s three big points you can make for a unitless line-height. Let’s walk through them:

It’s better for the responsive experience

One of the most common things we do in responsive design is change font-sizes to suit screen sizes. When design agencies treat line-heights as a value, rather than a proportion, it means that the typography can end up … a little off from one breakpoint to the next. We’re not delivering a consistent user experience when the line-height is re-written in every breakpoint.

It’s better for the end user if the typography is consistently different, whether from landscape to portrait, phone to tablet, or tablet to desktop. The “different” can be font-size, but the “consistency” can be vertical spacing.

The challenge, of course, is educating the design agency on the value of a proportion over a fixed value.

It’s better for the code base

A unitless line-height is written once, and inherited everywhere that it needs to be. Every time the font-size changes, the browser is doing the heavy lifting. It means fewer lines of code and fewer bytes of code. After all, 1.5em takes up twice as much space as 1.5.

It’s better for documentation

What’s easier to document?

This here:

	Font-size	Line-height
Mobile	12	16
Tablet	16	20
Desktop	20	25

Or this:

(line-height is 1.25)	Font-size
Mobile	12
Tablet	16
Desktop	20

When we have to document design specifications (and yes, we do on really big projects), the less data you have to focus on, the better.

TL;DR

For the web, precision is better than accuracy. Precision is consistency, while accuracy is proximity to a measured value. A unitless line-height creates consistent vertical spacing because it’s always proportionate to the text. A line-height with measured value makes it accurate to a design specification.

Using a unitless line-height guarantees that vertical text spacing is always perfectly proportionate to the size of the text. It improves the responsive experience, reduces code, and alleviates documentation.

The bigger challenge is to change our mindset to one that values proportions over precise pixels, and to teach design agencies to follow suit.