graphicpush

Thoughts on branding, design, writing and life by Kevin Potts. Established 2003.

When an Italic is Not an Italic and a Bold is Not a Bold

Using font-face is awesome for bringing a more unique design to life, but a browser’s native italic and bold rendering can be something less than complimentary to a strong body font. Use the type face’s native styles to create a more polished presentation.

We all know the overwhelming slab of awesome that is CSS font-face; with a clever stack of code (usually pre-written for us), we can deploy an array of tasty fonts beyond the moribund Arial/Verdana/Georgia stand-bys.

This is all great, except when it comes to derivative fonts of that type face like italics and bolds. Most of the fonts that are licensed for the web do not include a selection of alternates, even some of the best like Junction that are legitimate contenders for body copy. This is fine; it’s the choice of the designer. However, when a type face does include these options, they have to be specifically declared in the CSS.

Let’s use Bitstream Vera Sans as an example. It’s a type face designed for digital screens, and makes a fantastic alternative to Verdana for longer blocks of text. It also comes with the the fonts we need: roman, bold, italic and bold italic.

Here’s how we might declare the styles after defining the font-face rules:

 body { font-family: ‘BitstreamVeraSansRoman’, sans-serif; }
 em { font-family: ‘BitstreamVeraSansOblique’, sans-serif; }
 strong { font-family: ‘BitstreamVeraSansBold’, sans-serif; }
 

Why go through the effort? Here is a comparison of using “faux” styles versus declaring actual fonts:

Comparison of native fonts versus faux font styles

The difference is striking. The faux italic is overly slanted and the proper letterforms are lost to the browser’s rendering. For instance, look at the “a” character; the faux version is anemic, the “real” version has full, cleaner proportions for much better legibility. In the bold example, the faux version simply pads the original letters with more pixels, but the “real” version is far more economic in its character proportions, and looks like an actual font and not a poor interpretation of one.

The downside, of course, is the extra page weight. Pulling in the full font set requires 16 HTTP requests and 391kb (using just the one core font reduces the weight to 90kb). Using all four fonts may be acceptable for full versions of the site, but for applications meant for mobile, it’s pretty hefty, and best practice would say forgo style for utility and just use a type face native to the OS.

For text-intensive sites, where readability is important and the details matter, using the “correct” fonts does make a difference in the polish of the presentation.

, , , , ,