REMs And Viewport Measurements — Why You Shouldn’t Use Them Yet

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.

frames around canvases

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 // =18px

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.

Viewport Measurements

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.

Summary

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.

8 comments

  1. there is actually a rem unit polyfill out there (google these term) that will bring support for old ies (and maybe opera mini,but not sure though)…would be interesting if it would solve your problem! thanks for the article!

    • Thanks exside. I found the polyfill I think you were talking about. Is this it? If I’m reading right it converts rems to px for IE8 and below. If that’s the case I’d still have some reservations, but it would certainly make the calculations easier.

        • It’s like I said in the post. If I’m understanding correctly the polyfill falls back to px for IE8 and below. So the tradeoff is we make things easier on ourselves with the calculations, but we give up relative measurements in IE8 and below. I’m not sure if that’s a good trade.

          I’d rather do the extra work on the calculations so that IE8 and below can get ems instead of px.

          • Ah ok, see your point, for me personally that trade-off is completley ok =), basically I’m still using px everywhere (for font-sizes, shame on me) bc the whole em thing is so “ugly” to me, but your “trick” with setting font-size to 10px and using rems from there (which makes it much easier to use), I’m experimenting with them and if an old IE user doesn’t get a perfect result, I’m actually fine with it =)…

  2. I think it’s perfectly fine if you think the tradeoff is a good one. Obviously a lot of people do. I realize the title of the post is why you shouldn’t, but it’s really about why I don’t yet.

    I moved to using ems for all vertical measurements a couple of years ago. I might use a single px for a very thin border or some other occasional thing, but for the most part I’ve gone all relative measurements.

    So for me I don’t want to give up those relative measurements in exchange for easier math. I’d like the easier math, but it’s not all that hard as it is.

    I don’t think an old IE user has to see the exact same site by the way, but this is one place where they can if I’m willing to do a little more.

    Thanks for the discussion.

  3. The trick with the 62.5% is supposed to make life easier, but it’s also making things more complex. As explained here
    http://csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided/
    If you just keep body font size at 100%, in general you only have to set the size of a few headers (2em, 1.5em, 1.25em, etc), everything else can stay at 100%. No problem when nesting elements.

    The ‘problem’ with inheritance when using ems is also its advantage: it’s easy to scale things on a component level (see here f.e. https://medium.com/front-end-development/8f433689736f).

    So I think both rem and em have their strengths and weaknesses.

    • Thanks Matthijs. I can’t believe I forgot that CSS Wizardry post. I remember reading it when it was first published. I actually never use that trick. I like keeping the default font-size at 16px (100%). I’ve had several jobs where dividing by 16 was something you had to do all the time so it’s something I find easy to do.

      Thanks too for the link on sizing web components. That one is new to me. Interesting points and it’s given me an idea for another post.

      I agree that both rem and em have strengths and weaknesses. I think most things do. Once IE8 falls out of favor, rems are likely what I’ll use on most projects. For now I’m sticking with ems for the reasons I mention in the post. And now I have another reason to use them even once I move to rems most of the time.

Leave a Reply

Your email address will not be published.

css.php