Skip to main content

CSS line-height Units Explained

In Chris Coyier's recent article, "Fun with line-height!", he mentions that we often use unitless values for line-height so that it's proportional to the font size. This is only part of the story, and I was reminded of a Stack Overflow question that got me investigating more about how line-height worked with regards to the various CSS units.

If you're declaring the line-height on each element, you won't notice any difference. But if you're not crazy and using the first C of CSS (that's 'Cascading', by the way), then the inherited line-height might not work the way you expect.

Disclaimer: This is my understanding after doing some research and testing. I may not be completely correct.

TL;DR

When using a relative unit (em, %), the line-height is calculated based on the font size of the element where the line-height is defined. This line-height is then inherited, unchanged, by each of its descendants. So we end up with a line-height that is relative to the calculated font-size of some ancestor.

When using a unitless value for line-height, the line-height is recalculated for each descendant element based on its calculated font-size, and therefore always relative to the font-size of that element.

Types of Units

There are three different types of units we can use here:

Absolute
px, in, cm, mm, pt, pc
The size of these units is an absolute measurement. So no matter what context, 3px always == 3px.
Relative
em, %
These units are relative to the font-size of their containers, or browser default, if this is the root container.
Unitless
While technically a relative unit, this one behaves differently, at least in terms of line-height

Leading

The other thing we need to understand is leading, and how it's calculated for CSS.

Leading (pronounced like the metal, and not the action of leadership) is the white-space above and below the text. Historically, on printing presses, this was created using thin strips of lead (thus the pronunciation) placed between the rows of letters.

This text has a 5px leading (white)

To calculate the leading, we subtract the size of the font from the line-height, and divide the remainder in half (divide the space over the top and bottom of the text). 

leading = (line-height - font-size) / 2

Example: Calculating Leading with a Relative Unit line-height

When using a relative unit for line-height, the line-height is first calculated to an absolute unit using the calculated font-size of the element where the line-height is specified. This line-height is then inherited and used to calculate the leading for child nodes that don't explicitly define their own line-height.

Assume a base font-size of 24px.

Now you have a paragraph with its font-size set to 1em and a line-height of 1.5em. Within that paragraph is a span whose font-size is set to .5em;

The line-height is then calculated using the calculated font-size (24px * 1em = 24px) of the paragraph: 24px * 1.5em = 36px.

This gives a leading of (36px - 24px)/2 = 6px. So 6px above and below the text.

This calculated line-height is what is then passed on to the children. So though the font-size remains relative to the parent, the line-height does not change, and we get a calculated font size of 24px * .5em = 12px. But a line-height of 36px. Which means, using the smaller font-size, we will wind up with a larger leading.

(36px - 12px)/2 = 12px above and below the text.

Example: Calculating Leading with a Unitless line-height

When using unitless line-height, the line-height is recalculated for every element using its calculated font-size.

Let's again assume a base font-size of 24px.

Now you have a paragraph with its font-size set to 1em, with a line-height of 1.5. Within that paragraph is a span whose font-size is set to .5em;

The line-height is then calculated using the calculated font-size (24px * 1em = 24px) of the paragraph: 24px * 1.5 = 36px.

This gives a leading of (36px - 24px)/2 = 6px. So 6px above and below the text.

This time, the line-height of the span is recalculated using its calculated font-size: 24px * .5em = 12px.

So the line-height is now calculated using this font-size to give us 12px * 1.5 = 18px;

And our leading calculation now gives us a very different value: (18px - 12px)/2 = 3px above and below the text.

Demonstration

Since you can't inspect leading in any dev tools that I'm aware of, I put together a codepen to demonstrate the calculated leading for values that at first glance seem like they should be equivalent using borders.

You can see how you can quickly end up with strange problems if you don't use unitless line-height.

See the Pen Extra spacing between lines by Thomas Pietrosanti (@Rykus0) on CodePen.

Of course, we don't always use unitless line-height. There are situations where you want to specify a specific line-height, such as vertically centering text with an icon. But for the most part, if you're inheriting a line-height, you should drop the unit.

Labels:

Comments

Post a Comment

Popular posts from this blog

Be Careful Using SASS @extend, CSS3 Selectors, and IE8

I recently ran into a situation where some of my styles were broken in Internet Explorer 8. What makes this different from all the other times my styles broke in IE8 was that, as far as I could tell, it was correct. Consider the following code: %highlighted { background-color: #ff0; color: #333; } .keyword.is-active { @extend %highlighted; padding: 10px; text-transform: uppercase; } No problem, right? Then why isn't it working? I wasn't sure, until I looked at the compiled CSS and saw something like this: .some-list:nth-child(2n), .is-highlighted, .keyword.is-active { background-color: #ff0; color: #333; } .keyword.is-active { padding: 10px; text-transform: uppercase; } Since IE8 doesn't support the css selector nth-child , it ignores the entire rule . Without looking at the final output, there's no way of knowing if this will happen ahead of time. So what can you do? Well,...
Post a Comment
Read more

SASS Mixin for Creating CSS Triangles

I feel like one of the most common shapes that we can reliably create with CSS vs images is the triangle. One of the reasons for this is that it works as far back as IE7 (IE6 works, but doesn't support background-color: transparent ). Another is how frequently a little triangle icon can be used (e.g., ascending/descending buttons, expanding menus, open/close state, etc.) I'm not going to cover the techniques of creating triangles with CSS . That's been done already , and probably better than I would do it. What I'm going to share with you, is a little SASS mixin that I've been using to generate triangles. See the Pen SASS Triangles by Thomas Pietrosanti ( @Rykus0 ) on CodePen . I'm using a SASS placeholder ( %triangle-base ) as a base to contain the common styles. This makes it easy to extend without generating tons of extra code each time I want to make a triangle. When this compiles, it creates a rule that applies to all of th...
Post a Comment
Read more

SASS Converts Zero Opacity 'rgba' To 'transparent'

I recently had a strange problem after updating SASS. I have a modal dialog with a semi-transparent overlay behind it. For modern browsers, I'm using a CSS transition from rgba(0,0,0,0) to rgba(0,0,0,.5) For older browsers (namely IE8), I'm using some JavaScript to apply the transparency and animate the transition. To make sure the background gets set correctly, I'm using the standard fallback strategy of defining the background as background: rgb(0,0,0); right before the rgba line. This worked fine, until SASS optimized my code by changing background: rgba(0,0,0,0); to background: transparent; The reason? It's 2 characters shorter. Yes, we've now saved 2 bytes of easily compressible text in exchange for breaking my code. Why did it break? Well, if you haven't already figured it out, normally a browser that doesn't support rgba will simply skip that property and move on. But transparent is supported. So now, instead of h...
Post a Comment
Read more