Table of Contents for

The Modern Web

Units that are relative to the dimensions are helpful, but if you want to use a unit over which you have a little more control, you can use one that’s relative to a value that you set. The root em (rem) is a typographical unit, which like em is based on the width of a capital M character; the definition is not really important though, all you really need to know is that you can use rem for relative sizing.

Where rem differs from em is that the latter is inherited, whereas the former is fixed. For example, say you set a font size of 10px on the root of a document:

html { font-size: 10px; }

If you want to make a p element that’s 12px in size, you could use either one of them in this way:

p { font-size: 1.2em; }
p { font-size: 1.2rem; }

So far, so identical. But now presume that you have a b element inside that p, like this:

<p>This is <b>bold</b>.</p>

And you want the b to be 13px in size. Because em is inherited, you would have to divide the larger figure by the smaller to get the new font size:

p b { font-size: 1.08333em; }

Using em has the same two drawbacks you saw earlier in the chapter: long, unwieldy numbers that become harder and harder to work with and differences in rounding values between browsers. But the rem value, which is always relative to the root, doesn’t have these problems, making it much easier to work with:

p b { font-size: 1.3rem; }

Of course, although it’s a typographic unit, you can still use rem for length values in the same way that many people use em.

Two systems that I find really useful when building responsive websites are mobile first and breakpoints. These aren’t hard and fast rules—you don’t have to implement them if you think they’re not appropriate for what you’re making—but certainly for browser-based websites I can’t imagine building without them.

The mobile first methodology targets the smaller (and most probably lower-powered) devices first and then adds layers of complexity to accommodate larger devices. What this means in essence is you start with a set of styles that’s served to all devices—such as color, typography, iconography, and so on—as well as the minimal layout rules required for a small-screen device.

The next step is to add a media query that adds a new set of rules for larger devices/agents; this might be a tablet, for example. For anyone using an even larger device, add extra rules and so on, until you’ve catered to a core set of devices. If you imagine your core devices are mobile, tablet, and desktop, you’d end up with a set of style rules that looked something like this:

<link rel="stylesheet" href="base.css" media="screen">
<link rel="stylesheet" href="tablet.css" media="screen and (min-width: 481px)">
<link rel="stylesheet" href="desktop.css" media="screen and (min-width: 801px)">

The actual breakpoints you use are completely up to you; they depend on the devices you want to optimize for and should be based on analysis of existing visitors, if that information is relevant and available to you. The examples I’ve used here are simplistic and employed only to illustrate the method.

Luke Wroblewski is one of the leading proponents of this method. In the introduction to his book Mobile First (A Book Apart, 2011), he says:

The other approach to consider is setting breakpoints for content rather than devices. With the huge range of web-enabled devices on the market now (and plenty more to come in the future), the boundaries between phone, tablet, laptop, and desktop are incredibly blurred. The phone I own has a 4.65” screen. Samsung’s Galaxy Note has a 5.3” screen. Google’s Nexus 7 has a 7” screen. At what point does the device stop being a phone and become a tablet?

In my opinion, labels like phone and tablet (and especially portmanteau terms like phablet) are fast becoming obsolete. As the functionality of all our Internet-enabled devices converges, we’ll have to find a new vocabulary to describe these things (although I’m not going to presume to know what that new vocabulary will be).

My point in mentioning this is that the idea of building breakpoints based on device dimensions may well be a snipe hunt. Think about making breakpoints based on content instead; rather than thinking “how wide should my content be on a tablet,” think “what’s the maximum width this content can be before it becomes unreadable.”

What this means in practice is using media queries to change content, not when an arbitrary device size has been reached, but when that content becomes awkward. To illustrate what I mean, imagine I have a stylesheet applied to wide viewports using a media query:

<link rel="stylesheet" href="foo.css" media="screen and (min-width: 1000px)">

And within that stylesheet I set the width of an article element to be some 60 percent of the viewport’s width and a font to be 120 percent of the root:

article { width: 60vw; }
article p { font-size: 1.2rem; }

Many studies have shown that for optimal readability the maximum number of characters in a line of text is between 45 and 75, with 66 considered ideal, but if the user has a device with a very large viewport width, the width of 60vw may well lead to lines of text that could double that. Using the theory of content breakpoints, you may want to add an extra rule within the larger device stylesheet to make the text larger on much wider devices to restore some of the readability:

@media screen and (min-width: 1200px) {
  p { font-size: 1.4rem; }
}

Working in this way isn’t going to be easy—quite the opposite, in fact. You will have to perform a lot of testing and analysis and make decisions based on best practice and instinct. Some people, such as Thierry Koblentz in his article “Device-Agnostic Approach to Responsive Web Design,” have advocated using content breakpoints solely and not considering devices at all:

My opinion is that a combination of the two serves you best. As always, experiment and find your own system.