The Problem with Typography Complexity on the Web

Every now and then on OSAlert, we discuss typography and language. Despite the fact that many think it’s not relevant for computing – it most certainly is. Whether you’re browsing the web, reading email, or chatting over IM – the most common element on your computer screen is typography. Today, I want to discuss something we barely have in my native language: small capitals.

Small caps

Small caps are regular uppercase characters rendered as lowercase ones, a practice mostly used when setting acronyms like NATO. The reason behind this is that some assume that readers will find acronyms rendered in all-caps jarring, and using small caps will make the text easier to read. small caps can also be used as a method of emphasis (alongside bold and italics), and it’s used in chemistry to note optical isomers (whatever those are).

However, the use of small caps is not completely accepted by everyone. As a Dutchman, I find small caps jarring and unnatural, because they are rarely (never?) used here; when I’m reading English text (and I read more English text than Dutch, actually), I find that small caps interrupt my reading.

Apparently, that’s not a unique position to take. “What [small caps] actually does is inhibit reading: Acronyms are not regular words,” argues Joe Clark, “All-small-caps setting fools the reader into thinking an acronym is a real world. That discomfort you feel is a reverse fixation you underwent trying to reread the word.”

That’s not the only problem with using small caps. A more annoying problem with small caps was recently illustrated by a problem Al Gore had with the design of his new book. Al Gore and his designer chose Brioni as the font, but they ran into a problem with the numeral one in the Brioni font.

“In the book there’re a lot of examples of scientific nomenclature and this particular numeral one is causing confusion when it’s combined with capitals,” Gore’s designer told the Typotheque, the foundry behind Brioni. Consequently, the Typotheque changed the numeral one in Brioni.

Of course, the reason the numeral one was hard to read was because small caps were being used in the book. “It’s hard to read because of the fake bullshit rule that acronyms have to be typeset in small caps, even if they’re 21st-century acronyms that also include numbers,” argues Clark. Clark goes on to give some truly brain-dead examples of small caps usage.

On OSAlert, we obviously don’t use small caps, and we most certainly never will as long as I’m around. It’s no secret any more that we’re working on the next version of OSAlert, and I hope that in said next version, there won’t be small caps either. I’m personally still undecided about camel case, by the way – I say we ditch it, but the amount of complaints we’d get for defying the great companies and their marketing is keeping me from making said decision (and, of course, I’d need to get the rest of the team behind me).

Rendering small caps

My biggest problem with small caps is that software has a lot of problems rendering them properly – Chrome here does a relatively acceptable job, but they still stand out like an eye-sore. Let’s look at why that is the case.

Telling a browser to render small caps is easy using CSS:

<span style="font-variant: small-caps;">fiona rules</span>

Small caps should be rendered at one x-height, usually the height of the letter x. However, that’s not all there is to it; you can’t just reduce the point size of capitals until they are at the x-height of the rest of the text. For the best effect, they need to have the same stroke weight, and generally, a slightly wider aspect ratio. Some fonts include specific small capital characters, but for most fonts, software has to more or less take a wild guess, which looks woefully out of place.

For instance, see the below two examples:

Small caps in OpenOffice.org. Small caps in Microsoft Office.

The left attempt is from OpenOffice.org 3.1 on Ubuntu, using times New Roman, whereas the right attempt is from Microsoft Office 2007 running on Windows 7. As you can see, OOo messes up both the x-height and the stroke weight, while Office does a better job at stroke weight but completely misses the x-height.

I chose Times New Roman specifically, because where I’m from, that’s still the font in which schools and universities expect you to hand in material – a rule I’ve been defying for as long as I can remember (I despise Times New Roman). Interestingly, Linux does seem to render Times New Roman better than Windows does in the above comparison (note that I have messed with the default font settings in Ubuntu to achieve this result). It would be interesting if someone can send in a shot of small caps on Mac OS X (be sure to use iWork, since I’m not sure if Office:Mac uses the Mac’s default font rendering).

Update: A reader sent in a sample rendered by Pages on Mac OS X. It seems to get the x-height right (slightly higher than x-height is acceptable), but the stroke weight isn’t optimal (although not as bad as OOo’s):

Small caps in Pages.

OSAlert needs to render well on as many different browser and operating system combinations as possible. We’re not a fancy-pants hoity-toity design website (which, ironically, often tend to be illegible), so we can’t afford to just focus on whatever’s mainstream. As such, I stick to the basics: bold, italics, code, our quotation style, on rare occasions a strike-through or an underline, and I really like our chique h3 headers (see above).

On top of the we-need-to-render-properly argument, I dislike using too many different font styles in a single document. While some argue legibility is improved by using a different font and/or font style for every type of text (acronyms, names, headers, subheaders, links, etc.), I find it just leads to messy websites. I don’t want to tout my own horn here (okay, I do), but my own blog is rendered with just a single font, varied only by size (five, to be exact), colour (black, grey, red), boldness (headers and titles), and the occasional use of italics for emphasis.

There are no wildly differing fonts for every text element, no fancy coloured boxes, no lines, images, or other nonsense – yet readability is excellent and content is clearly separated by nothing but (gasp!) spacing. I do have to add, though, that I did not test for people with colour blindness or other possible disabilities, so my apologies for that. Another note is that Linux users may not have Trebuchet MS installed (sudo apt-get install ttf-mscorefonts-installer in Ubuntu).

What I’m trying to say is this: a lot of (web) designers tend to forget that usually, simplicity is better than complexity in typography, because the fancier and the more varied your fonts and font styles get, the less likely it’ll render properly. Small caps is definitely something that only adds complexity, which in turn hurts legibility. That problem isn’t as big in print, as you usually have complete control over how the end product looks. However, on the web – you don’t. As such, keep your typography simple and to the point.

I have little control over OSAlert’ redesign (at least, not until we have something resembling a finished product), but I hope that we keep our typography simple (that’s a hint!).

19 Comments

  1. 2010-01-12 3:28 pm
  2. 2010-01-12 3:32 pm
    • 2010-01-12 4:45 pm
      • 2010-01-13 1:38 am
    • 2010-01-12 7:44 pm
  3. 2010-01-12 3:36 pm
  4. 2010-01-12 4:12 pm
  5. 2010-01-12 4:24 pm
  6. 2010-01-12 6:12 pm
    • 2010-01-12 6:37 pm
  7. 2010-01-12 9:48 pm
  8. 2010-01-12 9:59 pm
  9. 2010-01-12 10:45 pm
  10. 2010-01-12 11:29 pm
  11. 2010-01-13 12:45 am
  12. 2010-01-13 5:04 am
  13. 2010-01-13 7:26 am
    • 2010-01-13 10:51 am
  14. 2010-01-14 11:26 pm