Measuring and sizing UIs, 2011-style

For years we used pixels to lay out web pages. Then, not so long ago, we were dabbling with ems to make our pages elastic. Now, in 2011, most of us are adopting a responsive approach and using fluid grids and percentages.

These methods seem to have all happened sequentially, with us each time dropping the last. I’ve decided, though, that the best builds use aspects of all previous methods; fixed, elastic and fluid.

Using percentages…

Let’s forget responsive design for a second. Responsive design is a three-tiered approach but here we’re only interested in fluid layouts (N.B. not even necessarily fluid grids). A fluid layout, as you all know, is one that is size-agnostic; it acts like a liquid, occupying a constant percentage of a varying space.

Now, fluid grids are a little tricky as they’re based around full grid systems. Luckily I’ve created a simple fluid grid calculator to work these behemoths out, but in more simple terms it’s remarkably easy to set a fluid layout even if that was never the intention.

If your designer sends you a two-column design then all you need to do is work out not how big the respective columns are, but instead work out how much bigger one is than the other. That is to say; stop thinking ‘this content area is 600px and the sidebar is 300px’ and start thinking ‘this content area is twice as big as the sidebar’. Percentages work well whether you’re going responsive or not!

Design is about proportions, not absolutes, and in ignoring actual pixel measurements in favour of relative ones you can ensure that designs are not tethered to numbers, but to proportions.

So the next PSD you get sent that is not meant to be responsive, just try this method out and at least make it fluid. If your sidebar is 220px wide and your content area is 640px then take that as meaning ‘the content area is 2.909 times bigger than the sidebar’.

…or using nothing at all

Even better than using percentages is to use no measurement at all. All components you build (navs, tables, figures, thumbnail galleries, banners, you name it) should never have widths (and never ever have heights) applied to them. They should be constrained only by their parents.

An element without measurements is inherently fluid, but in the best possible way; it will work wherever you put it. Ironically, the most important takeaway from this—an article about setting measurements—is simply ‘don’t’. Every time you can avoid setting a measurement, you should.

Using ems

Ems are an old favourite. They’re great for setting type, and with ems it’s all about the type.

As I outline in the next section, I don’t actually set font-sizes in ems; I use rems which is essentially ems-with-benefits. What I do set in ems is things to do with type; margin-bottoms on paragraphs, lists, headings and the like; paddings on buttons, nav links and promos and other such measurements; borders on promos etc.

What this does is ensure that the ‘feel’ of the design is maintained no matter how far a user wishes to scale their text.

Let’s take an example. A designer has made a PSD with a nav in it. The nav links are blocks with a font-size of 12px (0.75em) and a padding of 5px, thus.

Now, as I stated previously, a lot of design isn’t about numbers, it’s about proportions. It’s not about 12px and 5px looking best here, it’s about a link looks best when its padding is just under half its own font-size.

It can be a confusing way of looking at things at first, but once you realise that the 12 and 5 are actually totally irrelevant here and that it’s about their relation to one another, you should soon get the hang of things.

Let’s assume the user doubles their font-size, now you have a link that is 24px in size but still has a padding of 5px. That’s going to look very cramped. This is why we need to set paddings on text in ems, so that they track the font-size. In this case 5px as an em unit of 12px is 0.417, so now our code looks like this. Try scaling up these two examples up and see how the second looks a lot nicer when the padding scales too.

So, whenever you are setting a measurement because it looks good when set against nearby type (think borders, paddings, margins etc) try and forget the absolutes and begin thinking ‘this padding needs to be just under half of whatever the font-size needs to be’.

Not convinced that users scale their text all that much? Well I have no data but I love this thought provoking analogy from @5minuteargument:

“I’m going to start using TV volume as a CSS font analogy: not everyone is listening to your programme at the same volume…”

Please note that when I refer to scaling I don’t mean the browser’s Ctrl+[+/-] scaling/zooming, I mean a user stylesheet or design alteration that changes the base font-size of the document.

Line-heights

There are several ways of setting line-heights. A general rule of thumb is to never set them in pixels as this, as discussed above, won’t track your font-size. In this case you’d set them in ems or percentages, so that you never end up with ‘a font-size of 12px and a line height of 18px’, you’d get ‘text whose line-height is 1.5 times its font-size’.

However, even better than using ems, you just set them unitless. Work out the em value, but drop the em from the value, so line-height:1.5em; would just be line-height:1.5;. Eric Meyer explains this nicely over on his site.

To work out unitless line-heights is simple. Use the following equation: the line-height I want ÷ the font-size I have. Want a 20px heading to have a 30px line-height? 30 ÷ 20 = 1.5. A 12px button to have a 24px line-height? 24 ÷ 12 = 2.

Using rems

Despite my initial thoughts, I have now started setting type in rems (with a pixel fallback).

This gives us two things, firstly we have what I call ‘progressive accessibility’ in that it brings the accessibility benefits of ems but only in more advanced browsers.

Secondly, and more importantly, it gives us the confidence of pixels plus the scaling properties of ems. This is ridiculously cool. What this means is that we avoid the annoying compounding issues that ems can give us (a small in a smaller-than-body-copy promo springs to mind) but we can also keep their feature of scalability; we can alter the (font-)size of an entire document based on a parent rather than having to redeclare each individual elements’ font-size over and over. It really is the best of both worlds.

Take this example. Try changing the html’s font-size to 2em, does the page scale up as a whole? Nope. Try this one. See how just changing the html element’s font-size will make your entire page act accordingly. This is something that pixels can’t give us…

Interestingly, I also set margin-bottom in rems so as to always maintain a consistent vertical rhythm around my magic number.

Using pixels

I’ve said before today that the pixel’s day is numbered in the web design world. Most of my work involves ems, rems, percentages or nothing at all. The only time I ever really use pixels is if I have a known and fixed dimension to work to; nearly all the time this is images and icons.

Most pixel based measurements pertain to laying out fixed-size images like avatars or sprited elements who require fixed-size background images applying to them. Nearly everything else is best suited to proportional sizing with ems or to non-sizing with just being left fully fluid.

There really isn’t much work left for the old pixel in 2011.

An example

A fairly decent pre-existing example of the techniques discussed would be my hry.rbrts.me hub-site.

If you open that page and fire up your inspector you should see that:

Percentages: The body and articles all have their structure set in percentages.
Nothing: The social icons component is free of dimensions, it’s fully fluid and will always occupy its parent, wherever you put it.
Ems: The indentations of uls, ols and dds are all set in ems so that they will scale with the lists’ font-size. The gaps between sections are also set in ems so that if the font-size ever increases, so will the space around sections of text.
Line-heights: These are all set unitlessly (except the tagline which needs to line up with the logo).
Rems: Type styles are all set in rems to allow us scaling with control.
Pixels: Only the social media icons and the logo, which are fixed in size before we even start thinking about CSS, are set in pixels.

If you’d prefer, you can poke through the nicely formatted and commented CSS on GitHub.

Key points

The key things to take away from this article are:

Set structure in percentages. This includes content areas, sidebars etc.
Set type in rems with a pixel fallback for older browsers. This gives us a great amount of control with added scalability.
Set type-related items in ems so that paddings et al scale with the font-size.
Set line-heights in relative units. Or, even better, with no units at all.
Don’t set measurements on components at all. They should remain fully fluid and ‘just work’ wherever you drop them.

So there are a few tips and guidelines on sizing UIs and designs in 2011. We have a whole host of brilliant methods at our disposal and we can just cherry-pick them whatever they’re best suited to.

Tweet Follow @csswizardry

By Harry Roberts on Wednesday, December 7th, 2011 in Web Development. Tags: CSS, Sizing, Typography, Units | 29 Comments »

29 Responses to ‘Measuring and sizing UIs, 2011-style’

Chris Krycho said on 7 December, 2011 at 2:33 pm

Excellent stuff. The only point I would potentially differ on is the idea of not setting measurements on components – I like the idea where it makes sense, but as a universal rule, it’s not always sensible. For example, if you’re dealing with a nav element, you may or may not want it to take all available space – so either you style the component, or you’re left potentially adding lots of additional wrapper divs. I’m a fan of keeping the DOM as clean as possible, so I try to avoid wrapper divs as much as possible. If you’re using a fully fleshed out grid system, you’re already using the wrappers, so it makes sense to have components be free like that – but if you’re not, or you’re only using a conceptual grid without an actual grid implementation in the HTML/CSS (which tends to be more how I work), the elements themselves should still be measured.

Nice site and tools, by the way. :)
Matt Wilcox said on 7 December, 2011 at 9:18 pm

Nice article, makes a lot of sense. I’ll have to give REMs a go again (I tried them with my adaptive-images.com re-design, but I was also trying to align to a baseline grid – proper typographic baseline not the “baseline” most CSS toolkits talk about. Broke my brain)

When you say type-related things in EMs, I don’t understand why you’re not using REMs there? Surely the benefit is the same, if the user re-scales their type then the base REM is bigger and all proportions stay the same?
Harry Roberts said on 7 December, 2011 at 10:20 pm

“When you say type-related things in EMs, I don’t understand why you’re not using REMs there? Surely the benefit is the same, if the user re-scales their type then the base REM is bigger and all proportions stay the same?”

Kinda, but not quite… You want to ems to track the font-size of the current element, not necessarily the base font-size.

This example kinda demonstrates that. We want our padding to track our heading’s font size; the ems one does whereas the rems one tracks the <html>.

Cheers,
H
kchoppin said on 8 December, 2011 at 10:14 am

“Secondly, and more importantly, it gives us the confidence of pixels with the scaling properties of ems.”

I don’t understand this, pixels aren’t scalable are they? How is a pixel fallback like using em’s?

Or am I missing your point and you mean rem’s give the scalability and pixels are just a handy fallback for browsers that don’t support it?

I am also fond of this method (rems with a px fallback) but its a shot in the nads in regards to scalability for older browsers that don’t support rem isn’t it?
Stefan said on 8 December, 2011 at 10:23 am

Exzellent article. Give us more of this type.
Harry Roberts said on 8 December, 2011 at 10:47 am

@kchoppin: What I mean there is that rems carry the scalability of ems but they don’t have nasty compounding issues—they give us the confidence of pixels.

Perhaps it’d be better worded it gives us the confidence of pixels plus the scaling properties of ems…?
kchoppin said on 8 December, 2011 at 11:01 am

What I mean there is that rems carry the scalability of ems but they don’t have nasty compounding issues—they give us the confidence of pixels.

Perhaps it’d be better worded it gives us the confidence of pixels plus the scaling properties of ems…?

Ahh, yeah that makes more sense now you’ve explained it, thanks. I just misinterpreted it.

Great article by the way!
Alex said on 8 December, 2011 at 12:12 pm

There is absolutely nothing wrong with using pixels to layout websites, nor there is something wrong with non-fluid websites.

I wish guys who “think” they’re on top of the webdesign community stop saying those stupid things, cuz they realy are stupid.

not everything, everytime needs to be adaptive or fluid you know
Harry Roberts said on 8 December, 2011 at 12:58 pm

@Alex: Sure, but there’s no reason why they shouldn’t be…
Matt Wilcox said on 8 December, 2011 at 4:15 pm

I’m still not sold on that – what I don’t get is why you would ever mix REM and EM. Why not use REM at all times?
Harry Roberts said on 8 December, 2011 at 6:08 pm

@Matt: Because rems track the base font-size which is not necessarily the same font-size as the element that you are applying padding (etc) to.

You want your measurements to be harmonious with/proportional to the element to which they’re applied, not necessarily in harmony with the base font size.
Matt Wilcox said on 8 December, 2011 at 10:32 pm

I understand the argument for proportionality, but I just don’t follow why you would set any type units in ems if you’ve decided on rem. I thought the entire point was that you get all your units to track the base font-size for predictability. The advantage of REM is you have a solid base unit to work with without having to work out the weird maths of ems e.g.,

html { font-size: 1em; line-height : 1.5; } /* 16px/24px */

That sets the root em right there, so why use:

li { font-size: 1.5em; margin-bottom: 1em; }

instead of:

li { font-size: 1.5rem; margin-bottom: 1rem; }

With one there are never issues, with the other there are, and I can’t see the advantage of em. Ever. What am I missing here?
Matt Wilcox said on 8 December, 2011 at 10:33 pm

In fact, the only time you would ever want to use em’s is if you want measures to compound when nested. Which is almost never. Other than that, rems are always superior. Right?
Harry Roberts said on 9 December, 2011 at 9:20 am

The only way I can succinctly put this is:

If you want a measurement to track the element’s font-size then use ems. If you want it to track the base font-size then use rems.

Ems are useful if you want to scale a measurement based on that element in isolation, which is quite often. Ems are still massively useful.

Also:

“I [...] don’t follow why you would set any type units in ems”

I set type related units in ems. I set font-sizes in rems…

And:

I think your example was meant to read:
```
html { font-size: 1em; line-height : 1.5; } /* 16px/24px */

li { font-size: 1.5em; margin-bottom: 0.666em; } /* Equivalent to 1rem, 16px */

li { font-size: 1.5rem; margin-bottom: 1rem; }
```
Forgive me if I’m wrong :)
Matt Wilcox said on 9 December, 2011 at 11:33 am

OK, I’ll have one last go because I think I must be being monumentally dim at the moment for not being sure I’m getting this (it happens sometimes):

What you are saying is that we should set all font sizes in REMs, but after that use em’s, because they are relative to the elements given font-size, which we have just declared in REMs?

My confusion is that if you’re already making the element reference the base font size then you may as well do the same trick for everything else, because by definition the element is already tracking the base font size. It can’t change through nesting because you’ve set it as a REM, which means none of the em values ever change either. Meaning there are no advantages to using em once the elements font size has been set with REM, but it does mean having to re-do your maths.
Harry Roberts said on 9 December, 2011 at 12:22 pm

I really wonder where we’re getting tripped up here, it’s confusing the hell out of me!

I’m gonna start treating this whole thing as confusion rather than disagreement, this is how I rationalise my thinking: http://jsfiddle.net/csswizardry/zBTck/3/

Hope we manage to clear this one up!

H
Fabian said on 9 December, 2011 at 12:25 pm

Mhhh … http://csswizardry.com/2011/05/font-sizing-with-rem-could-be-avoided/ :)
Harry Roberts said on 9 December, 2011 at 12:32 pm

@Fabian:

I actually reference that in the article…

“Despite my initial thoughts, I have now started setting type in rems (with a pixel fallback)”.
Matt Wilcox said on 9 December, 2011 at 1:04 pm

Oh yeah, this is me getting confused – absolutely! I’m not disagreeing that what you say makes sense, just been having trouble seeing the resoning.

That latest example makes it much clearer, I think it finally clicked, thanks. That said, I’ve been using the 4th version over the 2nd because the root element for the math remains the same, which is more intuitive for me to get to grips with – everything is a divisor of the root, and so only need remember the root. I don’t care how “odd” the number it generates looks: I only have to remember that the root is 16px equivalent and work the px equivalent I want from there, instead of working out the element px equivalent and then using that as the base for a math expression.

But then I’ve also been doing a lot of work on baseline alignment, and i mean typographic baseline, not “css” baseline, which means I’ve been working with some very obscure values for offsets – not simple halves and such. In fact, I gave up on REMs and went px for http://adaptive-images.com – though I’d like to get that sorted out at some point. Perhaps if you have a look there you’ll see why I’m preferring to use pure REMs at the moment (but perhaps wouldn’t if I wasn’t aligning to baselines)

Regardless – great article :)
Harry Roberts said on 9 December, 2011 at 1:13 pm

Phew, thank goodness. I hate when simple concepts get confusing, bet we’d have solved this in ten seconds face-to-face!

All I’d say to this bit:

“That said, I’ve been using the 4th version over the 2nd because the root element for the math remains the same, which is more intuitive for me to get to grips with – everything is a divisor of the root, and so only need remember the root. I don’t care how “odd” the number it generates looks: I only have to remember that the root is 16px equivalent and work the px equivalent I want from there, instead of working out the element px equivalent and then using that as the base for a math expression.”

is that that will work fine if you do change the base font-size. If you leave the base as-is and only change the font-size on the nav, the paddings wouldn’t scale with it… This is heavily dependent on what you’re actually up to though.

I’ll have a poke through your source (ooh, err) in a bit, see what you’ve been up to :)
Nicolas Gallagher said on 9 December, 2011 at 4:50 pm

Most of this has been the case for many years. There was a brief interlude where some well known people promoted px-based layouts, but many people continued to use percentages and ems in their layouts and font-size declarations. The introduction of CSS3 media queries and the renewed interest in catering to varied devices means that relative-unit layouts are now back in a big way.

But using rem units and px units as fallback looks like it violates DRY principles and introduces a fork in your code. At different viewport dimensions, for smaller devices, you might want to change font sizes and that is going to involve changing lots of px declarations (for many mobile browsers that don’t support rem units) even though you don’t need to change all the rem declarations.

And setting indentations of ul/ol/dd in ems can be problematic when font size varies but the width of the container does not, because the amount of space left for content can increase/decrease quite dramatically. This is why all browsers will set the horizontal margin on these elements using px.
Harry Roberts said on 9 December, 2011 at 5:10 pm

@Nicolas: Depending on how you write your CSS you can keep the font-size declarations to a minimum. Sure, there’ll always be double the amount as not using rems but you can keep that half-number down quite easily (as I’ve done with the Sky Bet rebuild). You could also use a pre-processor.

With regard the indentations, sure, you’re right, but the situation would be quite drastic when you’re struggling for space. True, you can’t rule it out, but if a user has scaled their text that far I dare say they’ve got bigger problems afoot.

Cheers for the comment!
H
Matt Wilcox said on 9 December, 2011 at 5:54 pm

Oh definitely we would, it’s just part of the problem with using text for discussion – stuff that could be easily explained face-to-face sometimes isn’t :)

“If you leave the base as-is and only change the font-size on the nav”

That is a very good point, and one I had not thought of – definitely EM’s would be an advantage there. You’ve convinced me I should switch to your way of doing things.
Thomas said on 9 December, 2011 at 6:32 pm

“I’m going to start using TV volume as a CSS font analogy: not everyone is listening to your programme at the same volume…”

That quote about TV volume is completely useless. I don’t know anybody that uses a custom stylesheet. Most users don’t know anything about their browsers except that it allows them to view websites.
Jay said on 9 December, 2011 at 8:33 pm

I couldn’t agree more. The sooner designers and developers start adopting fluid layouts the better off the web and its users will be. Great resource!
GIGG said on 5 January, 2012 at 11:27 am

Didn’t we all give up on this when browser zoom became standard over font size increase.
Bobby Jack said on 29 January, 2012 at 1:23 am

@Thomas: since the quote was mine I’ll respond:

It wasn’t intended as some deep and meaningful revelation about web design, more as a comment borne of frustration at people who think it’s *impossible* for the font-size displayed on a website to be *any* different from what they see.

Moreover, I wasn’t talking exclusively about user stylesheets (which, I agree, are – unfortunately – underused); whilst Harry’s chosen to talk *not* about text scaling, I had that specifically in mind. Do you have any figures to back up the claim that “Most users don’t know anything about their browsers except that it allows them to view websites.”? In my experience, the very people that *really* need these features (i.e. those that are poor-sighted) *are* aware of them.

I’ve been recording the minimum font-size setting of visitors to my own site for some time now. Whilst the majority appear to not have changed the setting, there are significant numbers who have. Certainly more than ‘none’. And that’s just minimum font-size – one small factor that drives used font-size.

I think, all-in-all, “not *everyone* is listening…” is, therefore, pretty fair :-)
Mike Edward Moras (e-sushi™) said on 16 February, 2012 at 11:39 am

Pixels to EMs made sense as different hardware came up, but using REMs feels like using alien technology found in ancient ruins… if you really fail to keep track of EM scaling, you should polish your workflow instead of falling back on yet another unit that is bound to fail on older browsers and not used widely enough to be anything near future-safe.

Layout in percentages, put type and line-heights in EMs, flow the margins and paddings in EMs accordingly and wrap it up with a max-sized frame to make it float wherever you want and you’re done.

There’s nothing plain and simple maths can’t solve… so why expect a workaround from “yet another unit” if it doesn’t really makes sense? To follow the latest trend? If you do, you might catch yourself running in circles one day… along your path, we’ll meet again and I will say: “I told you so”. *grin*
Larry Botha said on 27 March, 2012 at 2:17 pm

@Mike Edward Morris: Does updating compounded em units as a result of nesting make sense?

Keeping track of the parent element font size throughout a complex site is ridiculous… why not reference a single font size, and perform calculations on that value?

rem units are not a trend or a workaround. They are a new asset in efficient problem solving.