Text

Lou Ferrigno Gives His Body 110%, Should You?

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.

Text

The Thing About Those Media Types

After my last blog post about vertical media queries, I received an intriguing tweet from Sparkbox’s Ben Callahan. He asked:

“Curious, why do you use ‘only screen and…’ by default?”

When someone like Ben asks you a question like that, you may quickly realize that you do not have a great answer prepared.

A few weeks later and we were digging into the implications of media types on Skype. Here’s the deal:

At Bearded we’ve been specifying “only screen” in our media queries. At Sparkbox they’ve been specifying no media type, which results in all media types getting their media query-based styles.

We both agreed that we wanted all screen-ish devices to get our responsive styles. What makes the situation a little less clear is that most media types that we’d want to get our media queries, but are not actually screen (handheld, projection, tv), often identify themselves as screen because … well, because nobody ever uses those other media types.

But the idea with responsive design is that we don’t know what’s coming down the road, and we want our flexible designs to handle those unknowns as best they can. Which means in general, we want all media types to get our responsive styles.

That in mind, the Sparkbox approach seems more appropriate. Everybody getting the responsive layout is definitely better than “only screen.” 

There are, however, some media types that we probably don’t want to get all of our extra styles. Print being the most obvious. Taking a whitelist approach of “screen, projection, handheld, tv” is not very future-friendly, as it would disallow future media types. So then we wondered: could we take a blacklist approach? Is there a “not” function?

Turns out there is. At first glance, this seemed pretty exciting. At first glance, this seemed pretty exciting. We both thought something like:

not print and (min-width: 60em)

… could be pretty useful – if the “not” only applied to “print.” Ben took the time to put together some tests to see how it worked, and unfortunately the results were a bit discouraging. It seems like the “not” keyword ends up applying to everything, media type and media query – which is less than helpful.. 

So now we’re back to the beginning. Is the best approach really just to not specify a media type (or specify “all”), and let everything get the responsive layout? Does this impact accessibility for types like braille, tty, or speech? We have no idea. And that, internet friends is where you come in. If you have any thoughts, please let us know on Twitter: @elefontpress & @bencallahan.

Update: Ben has written a follow-up with some great stuff on the Sparkbox Blog!