The Dilemma

While working on the launch of the Icavia.com website, we were committed to fulfilling our creative team’s vision and decided to use embedded fonts with @font-face. Soon after, we came across an interesting new dilemma. Not only did our embedded fonts render noticeably different between some browsers, but we also saw inconsistencies between operating systems.

In a less than pixel perfect world most of these minor differences can be overlooked without breaking a sweat. As a developer for a company that takes pride in their work, I have come to the conclusion that in the real world minor indifferences can become the weak link in an otherwise strong design. This is especially apparent when trying to vertically align text within a parent element.

As you can see in the screenshots below there is a small difference not only in the legibility of the text but also, and more importantly, in its position.

See it for yourself

As I was debugging the cause of this issue I decided to create a simple demo to test the nature of multiple fonts between browsers and operating systems. In the demo I remove all extra spacing from each elements and allow the font to dictate the height of each element.

View Demo

It seems as these differences can be boiled down to the font rendering philosophy used by each OS.

• Apple’s end goal is to preserve the design of the typeface at any cost.
• Microsoft’s end goal is to improve readability even if it effects the true nature of the typeface.

The difference in philosophies causes some fonts to be rendered noticeably different between operating systems.

Apple’s philosophy allows for a true depiction of the designed font and scales the font naturally. This comes with a noticeable side effect of allowing the font to dictate the descender and ascender heights.

Microsoft’s philosophy doesn’t represent a very accurate representation of the font and forces the font to fit within the pixel grid. This allows for a consistent vertical alignment of the font but at the cost of changing the properties of the font itself.

A Simple Solution

The true representation of fonts within OS X caused an issue with the vertically aligned nature of our menu. I first looked into a server-side solution to the problem by detecting the operating system used by the user and adding a few custom styles accordingly. We quickly realized that a server-side solution would break due to the nature of cacheing and WordPress. A client-side solution was the only possible answer. After some research into client detection I found a code snippet on quirksmode used to detect the browser and operating system of the user. Using this browser and client detection methodology I created a simple jQuery plugin that can be used to add a class to elements based on the client being used.

Download Plugin Demo

//Example Use of Client Plugin
$(...).fixClient({
    os: ["mac", "windows", "linux"], //excepts string, regex or array
    browser: ["firefox", "chrome", "safari", ...], //excepts string, regex or array
    version: 3.6, //excepts string or numeric,
    filter: function(){}, // custom filter function
    cls: "fix-client" //class to add to match
});

Client Plugin in Action

Below is the snippet of code used to fix the rendering issue described above.

//Fix Menu for Mac
$(...).fixClient({
    os: "mac",
    cls: "fix-mac"
});

Related Links

• Web Fonts at the Crossing
• Font Squirrel : @font-face generator
• W3C Fonts Module