By Harry Roberts
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Written by Harry Roberts on CSS Wizardry.
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
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.
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’.
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.
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-bottom
s 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.
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.
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.
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.
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:
N.B. All code can now be licensed under the permissive MIT license. Read more about licensing CSS Wizardry code samples…
Harry Roberts is an independent consultant web performance engineer. He helps companies of all shapes and sizes find and fix site speed issues.
Hi there, I’m Harry Roberts. I am an award-winning Consultant Web Performance Engineer, designer, developer, writer, and speaker from the UK. I write, Tweet, speak, and share code about measuring and improving site-speed. You should hire me.
You can now find me on Mastodon.
I help teams achieve class-leading web performance, providing consultancy, guidance, and hands-on expertise.
I specialise in tackling complex, large-scale projects where speed, scalability, and reliability are critical to success.