The original title was, “CSS’ Units of Measurement and their impact to the quality of responsive websites”, and then I thought, “I wouldn’t want to read that — there’s no way someone else would.” So I figured I’d try something semi-punny, and then hit you with the real title inside, like a journalist or something.
Whatever. Here’s the big idea:
It’s not 1999, or 2009. We can’t predict, reliably, what devices consumers will use to consume our content. Designing a website that looks a specific way in a specific breakpoint is getting harder to do, and it makes CSSing those websites more unruly. A factor that contributes to that unruliness is the unit of measurement.
There’s more than just
em to consider now. There are many other units of measurement that can have a positive impact in a responsive website.
The many ways to measure length
There are a ridiculous amount of ways to measure things in CSS. We can measure angle, duration, and frequency, to name a few. But for today, I’m specifically talking about measurement of length. These are also classified as “distance units” by the W3C.
The W3C breaks down these measurements into two distinct categories: absolute and relative.
Your absolute units of measurement are all based on real physical units . You could arguably say that they break down into metric or imperial units of measurement:
q: 1/40th of a cm
mm: 1 millimeter
cm: 1 centimeter
Imperial (thanks, ‘Merica)
pt: 1/72 of an inch
pc: 1/6th of an inch
px: 1/96th on an inch
What’s surprising here?
Two things: That the pixel is based on a physical dimension, that the physical dimension is an inch.
Your relative units break down into two sub categories:
Font relative units :
em: the computed font-size
ex: the computed x-height of the computed font-family
ch: the computed width of the 0 (zero) for the computed font-family
rem: font-size of the root element
What’s interesting here is that
emis a computed and inherited value, while
ch are computed based on the font-family for the element. And
rem is what a lot of developers love because it takes the unpredictability out of
em (more on that in a bit).
Viewport relative units :
vw: 1% of viewport width
vh: 1% of viewport height
vmin: 1% of the smaller between vw/vh
vmax: 1% of the larger between vw/vh
These are the newest units of measurement, older versions of Safari and Android may not play well with these.
Which one is better?
Each unit of measurement has strengths and weaknesses for a given situation. So let’s talk about how to generally decide which kind of unit of measurement works for a situation.
- You are writing a stylesheet for content that will be consumed in a physical medium where you can predict exact physical dimensions and exact physical outcome. Most frequently, this means print styles.
- You have a design agency that insists that their design is the flawless, unchangeable and everlasting embodiment of perfection. To change even one pixel of their design is to destroy the essence of its meaning.
You’ll pick the appropriate absolute unit of measurement based on the medium and the culture. e.g.: a print medium in the US may use
pt, a print medium in Europe may use
cm, a print medium for hobbits or possibly Ant-man will use
Keeping it relative
Your relative units of measurement are better under three situations:
- You cannot reasonably predict the exact physical dimensions of the physical medium that is presenting your content. Most frequently, this is a screen size
- You have a need for typography to scale up or down. You may need to scale this content for accessibility purposes. You may also need to scale this content because these are reusable components that may display differently depending on the context
- You have a design agency that emphasizes relationship and proportion over pixel perfection.
You will pick the appropriate relative unit of measurement based on the property you are using, the element you’re using, and the medium. e.g.: vw for the width of navigation on a homepage, em for the font-size of a header, % for a width of a column in a grid.
On being pro-pixel
I don’t hate the pixel. It has its place. It just doesn’t have much of a place in responsive layouts. I find that other, relative units of measurement, are much better than the pixel.
Some developers may argue that you should use
px in your screen layouts, as well as for your font-sizes. And they will make the case that “it’s going to be a pixel anyway, so at least I know what I’m getting”. This is a weak argument.
Relative units of measurement are not unpredictable.
Quite the contrary, they all behave in extremely predictable ways. People are unpredictable, however, and they may use code in unpredictable ways. If you don’t use anything other than
px because you don’t know what you’re getting, whose fault is that? GiGo, guys.
Now it is true that on a large team, a website built on relative units of measurement can become problematic. Best practices, code documentation, and education mediate the “unpredictability” that you’re blaming on the browser.
Other times, the argument is, “I use pixels because there’s no debate about whether it conforms to spec.” This, too, is a poor argument.
Your users will never know if your website is, “according to spec”.
But they will know if “this page breaks when I zoom in” or, “it doesn’t work with my own font settings”. They will know that it’s harder to read the text on a phone because the line-height was set in pixels.
Testers are notorious for insisting on pixels, too. If something isn’t sized in
px, the tester has a harder time determining if the developer followed spec, and it means more questions in the test cases. This has caused countless developers to size things in
px for no other reason than to avoid a failed test case.
If your testers are measuring pixels on a screen, you’re doing it wrong.
So what’s best for responsive design?
Relative units of measurement, in general, will serve you better. So long as you’re in the mindset that a responsive design values proportion and ratio over precise pixels. Think, “precision before accuracy”.
Media Queries like absolutes
px for layouts, but use ’em in your media queries. You can use the inch or cm for print, too. Some folks have used
em, but The latest version of Bootstrap switched from em to px for good reason. 
The actual text is probably best set with
em. A List Apart recommended em as far back as 2007 .
If the typography is for numbers, then you could make the case for
ch, since it behaves the same way as
ex, but on the zero
0 glyph (meaning it’s a precise measurement of numbers for the given font).
For those things that wrap your typography, you’re probably best off measuring with a mixture of
Em is recomputed every time font-size is changed. So using
em and changing font-size multiple times can mean that you may get some unpredictable results.
For typographical spacing, I like using
em for vertical padding /margin, and
rem for horizontal padding /margin. This combo allows me to scale a text element up or down in size, while keeping it left/right aligned with all of the other content on the page.
I find that
ex is incredibly useful when I need to style
::after for things like list items, headings or icons. This is because
ex is giving me a spacing that is relative to the actual font. I can make sure that bullets and icons are spaced appropriately from the text.
If you need a container to wrap text in small breakpoints, but stay on one line for higher breakpoints, set a
vw at your smallest breakpoint. As the browser window gets larger, so will the max-width; this saves you the need to write CSS in higher breakpoints to undo the CSS in lower ones.
Dimensions can go any number of ways. I used to love sizing everything in
em, and then just changing font-size at different breakpoints. That gets dangerous though and it can cause a lot of FOUC (flash of unstyled content).
em is not good for sizing up the containers and wrappers of content.
I find that
vh can be incredibly valuable because you can make headers, footers, navigations all proportionate to the viewport. These units are especially useful in those cases where you are three or four elements deep, and
% is no longer a percentage of the window. When that happens, it’s vw/vh to the rescue!
px may still be useful for setting dimensions of images and videos, though. Rich media can scale down fine, but it doesn’t scale up well. You may set a width in
% or vh/vw, but still put a
px so that it doesn’t scale too large and look distorted.
Historically, when we’ve used
position:fixed, we’ve set our left/right and top/bottom in
px. That works great, but how do you keep something fixed to the very bottom in all those portrait and landscape modes? Once again, enter
vw. Now you can make sure that something is always fixed to a position that is relative to the viewport and not some arbitrary point in space.
Syndicated pieces of content, modules, or “component templates” if you’re a Tridion developer, are probably best with a mixture that include
rem. Chris Coyier has a solid case for setting your root font-size in
px.  You’d then size your modules with rem, this way you don’t get those unpredictable font-size computations.
Consider stepping out of your comfort zone. Don’t look at a web design as a collection of points in a grid that produce height and width, and position. Instead, look at a web design as a collection of ratios and proportions.
- Is that
<h2>really 24px, or is it 1.5x larger than the standard font?
- Is the video really 600px, or should it always take up about 2/3rds of the screen?
- Should that bullet always be 12px to the left of the text in your list, or is it simply 3/4s of the font-size?
It’s not just pixels and ems any more. it’s a great big world with lots of options. There are lots of great ways that we can size and position things that make websites respond well to the the users that are using them.