Apropos of nothing, I thought I’d write up a brief summary of when and how to use which units in CSS. I’m taking it for granted that these days, responsive is the way to go. I’m not going to be religious about this – if you disagree, or if the specific project you’re working on merits a static design, great.
That is, the font-size
on the HTML element. This trick predates the whole responsive thing, but whatever. I’ve seen in mentioned quite a few times recently. For reference, the default base font-size
is 16px
in pretty much any browser. If we want to use responsive-friendly units like em
and rem
, it’s nice not to have to do hideous maths and end up with numbers like 1.5625em
to replace 25px
.
One approach is to set the base font-size
to 6.25%
. 6.25% of 16 is 1, so this gives 1(r)em
equal to 1px
. That’s definitely convenient, but it makes me a little nervous:
It might kick up a fuss with minimum font-size
values in browsers;
Failing that, I can just imagine something borking somewhere, leaving all the text on the page one pixel tall.
Maybe I’m just being paranoid. Either way, I am totally on board with the basic principle. I’d personally go with a font-size
of 62.5%
, to give 1(r)em
equal to 10px
:
If something does bork, text will be a bearable 10px
;
This should be high enough to avoid any minimum value nasties;
Converting from units of 1 to units of 0.1 is trivially easy. Hopefully, anyway.
It’s worth noting that I would immediately change the font-size
on the body back to at least 16px
– or should I say, 1.6rem
… See? So easy. I don’t think there’s ever a reason to go much smaller than that for body type. In fact, I’m leaning more and more towards 1.8rem
as the default.
Really, with very few exceptions, work in rem
. If browser support is going to be an issue, then fire up some px
fallbacks – but really…? Honestly, I struggle to care.
Once you’re in rem
, everything will scale nicely, and unlike em
you won’t have any problems with cascading. Don’t get me wrong: I like em
, and they’re definitely better than px
. But boy is nesting a PITA. You have to get so specific:
You get the picture.
If you’re going for the full flexi, percentages are your friend.
As in, locally relatively-sized. For example, <small>
: the point is not to be a specific small size, but to be smaller than the surroundings. In these cases, em
has our backs – just like in the good ol’ days.
So say we have a big chunky border. We probably want that to scale with everything else, right? It’s meant to look big and chunky at any size, and we don’t want it getting dwarfed by the text or anything. Easily done: use rem
.
However: what if our border is just a single-pixel straight line? We probably always want it to be a single-pixel straight line. Even at really high zoom. At which point we introduce… px
! Hey, px
; haven’t seen you in a while.
A brief aside about high-DPI displays: we can’t use a half-pixel value, so we can’t get an ultra-crisp line. Fortunately, Brad Birdsall has a really genius solution to the issue. This is super elegant. Bonus points because, while not all browsers and devices support box-shadow
… chances are that anything with a high-DPI display does.
Work in em
. Why not rem
? Well…
I’ve had problems with it simply not working. Possibly PEBCAC, but I can’t honestly recommend it;
You wouldn’t gain anything from it anyway, as you’re about to find out.
Media queries seem to reference the user agent stylesheet. Hopefully you’re working with the super-convenient font-size: 62.5%;
, but you’re media queries aren’t. Nope: they’re still based on 100%
, or 16px
. You have to bear that in mind when you’re setting your breakpoints.
If you’re using percentage widths, this is less of an issue – presumably you just tweak the media query breakpoint until it looks right. If you’re like me, and almost always work to a 16px
grid anyway, the maths is mercifully straightforward. It shouldn’t be too big a deal in any case.
Given this quirk, though, why bother to use em
at all? Why not just work in px
? Well, we are at least trying to be responsive here… This way, if the user has a different browser default font-size
set, then the layout will survive, and breakpoints will fire in the appropriate place, relatively speaking. Again, it’s less of an issue if everything’s in super-flexible percentages, but it’s still a sensible move.
I guess we should expect to see more of vh
, vw
and vmin
. Nice, flexible font-sizes to go with our flexible layouts. As support improves, I suspect we’ll see more and more semi-static
layouts, which look the same but scale with the browser, with the occasional breakpoint when things start to look awry. In the meantime, stick to rem
for almost everything, and set a nice, large base font-size
for easy reading, and all will be well.*
* I can’t actually guarantee that all will be well.