by Matt Griffin
The other day, Patrick and I were discussing approaches to setting the base font size of our websites. When we use relative measurements like ems, you see, that relative measure has to come from somewhere. Historically we’d do that by setting the font-size of the element. There have been several approaches over the years, and perhaps most recently the Filament Group made a compelling argument to set it at 100%. The points they make are great, and it’s an approach we’ve been using on our sites for a while.
But here’s the rub: 100% (using default browser settings, that translates to 16px) is not a good default font size a lot of the time. Paragraphs are often too big at that size, which mean they need to be set to a lower size, like 0.875em (14px). Once the paragraphs are that size, you generally want other elements to line up, so then you have to set your unordered and ordered lists. And the headings need to fall in line at related sizes, too.
So, OK, not so bad. Your type is all worked out, right? Well sure, until someone uses a table or a definition list. Then we have a problem again. And this is exactly the situation that bit us just after launching the new site for the Pittsburgh Glass Center. It was an edge case kind of thing, and I doubt anyone besides myself noticed before I fixed it, but – it’s the kind of thing that makes feel like our approach is too brittle. It requires too much attention; it’s not an extensible solution.
What I really wanted to do was to start with body { font-size: 87.5%; }, then add some media queries to scale the font size up and down, as necessary, for all elements. Why media queries? Well, something the web world knows from graphic design is the idea of a readable measure. Basically, as line length increases, font size should also increase to limit the number of characters per line and aid in readability. (Trent Walton describes the responsive web approach quite well on his blog.)
This approach left us with something like this:
body {
font-size: 87.5%;
@media (min-width: 55em) {
font-size: 100%;
}
@media (min-width: 70em) {
font-size: 110%;
}
}
This has the effect of scaling the base font of everything from 87.5%, to 100%, to 110%. But starting the base body size at less than 100% felt a little weird to me, for all the reasons in the Filament Group post.
Now this was about the point where I decided (as I often do with issues like this) to bounce the idea off Ben Callahan. Ben was pretty much in the same boat as us. He’d been following similar practices, and also saw the brittleness as an issue. But he had a different perspective on font sizing to contribute. Ben took an issue with our assumption that font size and container width have a linear relationship; that as the container width goes up, so must font size. His feeling was that 100% was actually a great place to start on small screens, simply because touch targets need to be larger, and you’re often holding the little screens further from your face. Small browser widths, he argued, often mean small devices, which users interact with differently than, say, a low width browser window on a desktop computer. Small type on a small screen may have a short line length, sure – but it’s just too darn tiny to read.
Not only did all of that make sense, but Ben’s approach also got us back to a default font-size of 100% – which feels a lot less heavy-handed and hacky.
After factoring in Ben’s idea, we ended up with the following:
body {
font-size: 100%; // This actually happens in the reset stylesheet.
@media (min-width: 40em) and (max-width: 55em) {
font-size: 87.5%;
}
// In between these two media queries we go back to 100%.
@media (min-width: 70em) {
font-size: 110%;
}
}
This final approach has the effect of scaling the base font of everything from 100%, to 87.5%, back to 100%, and finally to 110%.
We’re feeling like this covers all the main bases for us, and it’s the approach we’re including in our front-end starter kit. Until, of course, we think of something even better.
Follow-Up
Trent Walton brought up some good points on Twitter, where he wondered if we should be making our type smaller at all. His point being that right now we tend to associate touch screen interactions with smaller screen sizes, but that this is not a very future friendly mindset, considering where things are going.
Perhaps we’re seeing my own aesthetic preference for slightly smaller type get the better of my desire for extensible multi-device UX, here, eh? Definitely something to keep in mind as we test our designs on devices. Regardless, it’s probably best to assume that any size at all may very well end up on a touch screen, with all the UI needs that entails.
