Designing for the web means designing flexibly. It means dropping absolute measurements and adopting relative ones like em and %. There will be exceptions, but for most things you should be using relative measurements.
Ever since I started designing responsively, I’ve been working with % for horizontal measurements and ems for vertical measurements. I rarely use px any more. You’d think I’d also use relative units of measurement like rem, vw, vh, vmin, and vmax, but to this point I haven’t used them in any way.
While they appear useful, each has given me some pause and reservation that’s kept me from using them in practice. I’d like the share those reservations along with what each of these measurements does in case you’re unfamiliar with them.
Root em (rem)
You don’t have to work with em units long before encountering a couple of difficulties. First is the math.
- 12px (target) / 14px (context) = 0.857142857em (result)
Not exactly the nicest looking result. I’ve come across this particular string of numbers so frequently it’s now committed to memory. It’s common to deal with long strings of numbers like this when working with em units. I prefer numbers like 1.5, 1.8, and 2.4.
Before you opt for rems and viewport measurements think about what’s gained and lost with each
The other difficulty is that it’s easy to lose the context when you nest elements. The heading in the main content needs a different value than the same level heading in the sidebar and both are relative to different containers with different em values. It leaves you overriding more values than you want and it’s easy to get confused.
The root em (rem) unit solves both problems. Instead of being relative to the parent, the rem is relative to a single root. There’s no getting lost in the context, because the context is always the same. It’s always the font-size of the root element, which is the html tag.
How easy the math is or isn’t depends on the root value, which by default is the equivalent of 16px. Dividing by 16 is not messy or difficult. It’s the kind of math you can do in your head after a little of practice.
If division by 16 sounds scary, you can use the trick of setting the font-size of your html element to 62.5% (10px). I hope everyone agrees that division by 10 is simple and undeserving of sympathy.
1 2 3
html font-size: 62.5% // =10px .sidebar font-size: 1.4rem // =14px h2 font-size: 1.8rem // =18p
Browser support is very good. Only IE8 and below and Opera Mini don’t support rem units. It’s possible you may not need to support either for a project.
Given how easy the above is why do I have objections? My reservations are in the fallbacks for IE8 and Opera mini and the reason for using rems in the first place. We use rems because they’re easier for us to work with. They don’t offer any specific advantage over ems other than being easier for us to work with.
Now consider the fallbacks. For browsers that don’t support rems you need to fallback to another unit of measurement. One fallback option is ems, but if you have to calculate ems it defeats the whole point of using rems in the first place.
The other option is to fallback to px, which is what most people will do. Typically you’d set up a mixin in Sass or Less. Easy enough, but it means we’re falling back to absolute measurements, which I’d also argue defeats the point.
I’m all for rems and prefer to use them over ems, however, let’s remember they exist solely to make our lives easier. Nothing is gained from them except saving some math and helping us not get lost in the context. Both are valuable things to gain, but are they more important than what you might be giving up? The answer depends on the specifics of your project.
One other issue is that rems don’t quite work as you’d expect in media queries, which you can see in this demo. It’s easy enough to set media queries using ems, though. It still means the possibility of some not so tidy looking values, but it doesn’t come with the nesting issue. So while this is something to take into consideration, I don’t think it’s that big of a deal.
Once Opera Mini offers support and once IE8 falls completely out of use I’ll be using rems regularly. When I have projects where neither needs to be supported I’ll be using them as well. They are certainly easier to work with. However, until then I’ll suck it up and do the math required to use ems most of the time. Sure it can be confusing, but it’s not exactly difficult.
Where rems size elements relative to the root size, viewport measurements size elements relative to…you guessed it, the viewport. Seems like something useful don’t you think? Let’s take a look at the measurements.
- 1vw = 1% of viewport width
- 1vh = 1% of viewport height
- 1vmin = 1vw or 1vh, whichever is smallest
- 1vmax = 1vw or 1vh, whichever is largest
At first you might wonder what’s the big deal with something like vw as it looks like another way of setting an element as a % of the whole, but keep in mind with vw the context is always the viewport and not the parent element.
When you nest elements, % can get messy the same way ems get messy. It’s easy to get lost and forget the context a few levels deep. With vw the context is always the same, the viewport.
Browser support is similar to the support for rems. It’s not quite as good, but it’s close. IE9, IE10, Blackberry and IE Mobile have partial support in that they don’t support vmin and vmax. Opera Mini and IE8 offer no support at all.
Once again we have to deal with the same fallbacks of using another measurement. If we select something relative like %, we might as well just use % everywhere. If we select something absolute like px, we have to ask if we’re gaining enough to give up relative measurements in some browsers.
I think there are bigger issues, though. Some have suggested using viewport measurements to size text. This is an awful idea for most text, which shouldn’t be sized based on the size of the canvas, but rather your distance to it. I don’t want the text on my phone to be 20% the size of that same text on my laptop (roughly the difference in viewports) It can be a little smaller because my phone is usually closer to my eyes when reading, though not that much.
Speaking of the canvas, I thought a big part of this responsive revolution was understanding that we should be designing content out and not canvas in.
I do think there are some interesting use cases, though. For example you might want the size of an element to be 100% the height of the viewport. It’s not something I typically want, but some do and it’s not that easy to do with css. Using vh it becomes quite simple.
Despite it not being a good idea for text in general, viewport measurements are useful for some pieces of text. Say a heading which you want to always span a certain amount of the viewport. That text likely remains large enough to read regardless of device. Light boxes are another good example where size relative to the viewport is a good idea.
I’ll stick to other relative measurements for now. Even when browser support is 100%, I’ll probably only use viewport measurements sparingly and for particular use cases. I do think they’ll be very useful for some things, but not everything.
If you’re not yet using relative measurements, you should be. We don’t design for an absolutely sized canvas and so using absolute measurements doesn’t make sense. Two types of relative measurements you may be tempted to use are root em and the various viewport measurements. Before you do, think about what is gained and lost using each.
I’m excited to use rems, though not until browser support is complete. The fallbacks don’t make any sense to me. They defeat the point of either an easier calculation or using relative measurements. I have similar reservations about viewport measurements and wonder if we should be sizing anything relative the canvas beyond a few small cases.
I expect rems to eventually become the standard unit for sizing text and vertical measurements in general. I’m not so sure about vw, vy, vmin, and vmax. Some will see them as standard units, but I don’t think it’ll be the case for the industry as a whole. Rather I think they’ll be very useful for some use cases, but not all.
Do you currently use rems? How about the viewport measurements? If so, how do you find them in practice? If not, do you share my reservations or do you have some of your own?
Download a free sample from my book, Design Fundamentals.