A Closer Look: The Font Sizing Choice

In yesterday’s (inaugural) installment of A Closer Look, I explored the color palette of the new farukat.es and explained the decisions behind the grayscale design. Today I discuss the typography in a little bit, focusing solely on the use of px for font-size units instead of a relative unit type.

First, I’ll explain the repercussions of using either approach, for those not widely familiar with the matter. When specifying font sizes in your CSS, you have a number of unit types to choose from, each behaving differently. More importantly than how the unit type itself behaves, however, is how browsers behave differently when dealing with the different types.

For instance, Internet Explorer—up to and including version 8—does not scale any text that is specified with a font-size property using the px unit, e.g. font-size: 12px. The pixel unit scales up and down in all other browsers when the user chooses to increase or decrease text size, which can be done via a simple keyboard shortcut (cmd and +/- on the Mac, ctrl and +/- on Windows or Linux). Yet because Internet Explorer until version 7 offered no way of scaling text that was specified in pixels, it was considered a serious accessibility and usability concern to use that unit type. After all, not everyone might be able to read the small type of your body text, and if they’re unable to increase the type, well, it’s a problem and you might lose visitors.

Then Internet Explorer 7 came around and offered what is by now available in every major browser, something called Page Zoom. The difference between Page Zoom and Text Zoom is subtle but important: rather than scaling only the text on the user’s command, Page Zoom will scale the entire page as a whole—images, text and embedded media alike.

This solution offered a lot of benefits to users, as oftentimes text was embedded in a web page as an image, and thus wouldn’t scale alongside raw text in the page using the Text Zoom method. With Page Zoom, that problem was solved and the design remained intact—more or less, anyway: there are small pixel-precise difficulties with zooming image-heavy page designs, but these are mostly minute issues and few casual observers ever notice them.

Until Page Zoom came around, Web Designers that were conscious of these accessibility and usability concerns for Internet Explorer users were using relative font-size units, such as em or percentages. These units, however, proved to be somewhat frustrating and problematic to use; most every website is designed in a pixel-based manner, and translating from 12 pixels to an em unit value that matched it precisely sometimes led to values like “0.825” or “1.6666”—suffice it to say, not the most convenient of values to work with. Being relative units, these values were calculated based on whatever their parent element’s specified font-size was, and so the inheritance and cascading nature of CSS meant that designers and developers writing CSS had to keep track of these things very carefully and precisely.

Today, the situation is that Internet Explorer 7 and 8, along with every other browser that has any notable market share, support Page Zoom and will scale pixel-based font sizes just fine. The question that Web Designers are now asking themselves again, but coming from the opposite side, is: What unit should I use, px, em or %?

This discussion is very much alive right now among web designers, and will continue for some time. There is no exact “right” answer to that question, as the answer varies from website to website. If you have to support IE6, still, and want to make a more accessible and user-friendly site, you should stick to relative units so that text can scale in that browser. If you don’t (have to) care about IE6 much at all anymore, there is no usability concern to using pixel units for your font size specifications.

But again, the discussion about this is ongoing and not everyone agrees with my point of view. One such example is Drew Mclellan, who recently argued that relative units for font sizes are better, so that they scale along to any base-level changes you make. As he puts it:

Take that H1 as an example. If the design dictates that the H1 is three times the height of the body text, you might specify the body text as 12px and therefore set the H1 to 36px. If, six months down the line, user feedback tells you the the text size is too small, you might come along and tweak the body text to 13px. In doing so, you’ve compromised the design, as the H1 is now not three times the height of the body text, so you have to adjust that up to 39px. And the H2s are no longer twice the height, so you adjust those to 26px, and the sidebar and footer text is no longer… and so on. A nightmare of changes and recalculations for an extra pixel on the text size.

The problem I personally have with this rhetoric is that just because the body text proved to be a touch too small in his hypothetical example, doesn’t mean that the headings were proportionally too small as well. It’s entirely possible that the headings were fine and that they were proportionally too big for the original body text.

Changing a base text and having all text headings scale along can have problematic and unintended (or unexpected) side-effects. For instance, your design might involve headings in a sidebar or column that are nicely tailored (visually) to cover most of the entire width of the column. Now you go and change the body text for improved legibility, and what happens is that some of these headings start wrapping to two lines because they no longer fit their containing column.

Ironically, Drew claims that:

When I want to tweak the body text, the integrity of the design is maintained, as the CSS is expressing the rules behind the design, not just the execution of the design.

It’s true for a site where all text exists only in one single column and the design is predominantly minimalist. However, even here on my own site’s minimalistic design, certain things would break if I were using his approach, and the integrity of my design would actually fall apart as a result.

I can appreciate the thinking behind Drew’s argument, but it’s simply not how I make my design decisions for type at all. He argues that with pixel units for fonts, you have to manually adjust each heading accordingly, but in all of my website designs thus far, the opposite has been true for me.

He does point out something that I completely agree with, which is this:

Regardless of the way you choose to scale text, the most dangerous assumption you can make is that what you’re looking at will never change.

To understand [why] page zooming is a complete red herring you have to understand this: the property of being able to cope with resized text is more important than the size of the text.

Drew nails it with those two bits, as the most crucial thing to keep in mind as a web designer and developer is that you simply cannot control all aspects of the site you’re creating. Web Design is an inherently flexible industry and the products are unquestionable going to be adjusted and controlled, to some extent, by the end user themselves.

In the end, what’s far more important than whether you choose to use pixels or relative units for your type is that you design and build your site in a way that is flexible to the user as well as to yourself, with regards to maintaining it as time goes by. Make sure you consider that a top priority; meanwhile, Drew, myself and others will continue discussing this subject until there is a clear consensus. If ever.

Further reading:

If you liked this, you should follow me on Twitter!