Koodoz Design

Another arrow for the web designers quiver…

The @font-face CSS property is a relatively new kid on the block, and it’s supported by all the major browsers, even IE7! All in all it’s a fantastic tool for web designers to embed fonts into their websites, and it out-does the aging methods of image replacement and sFIR Flash Replacement.

Even though it’s not that new, it looks like there’s still a teething problem or two out there.

Computer says no…

We stumbled upon such a problem when recently implementing @font-face across the whole Koodoz site. We’d started using it for a few of our recent websites and it’s been working perfectly, but for some weird reason, on the Koodoz site it just wouldn’t work with Firefox, although it worked perfectly in Safari and Chrome. Strange huh?

Debugging

So thus began the process of stripping the entire site piece by piece down to core, until the whole site consisted of just one title, the typography CSS and the font itself. And still it didn’t work! The code was fine, there was nothing that could be clashing, inheriting or over-riding, and we’d tried many fonts – including the ones that were already working perfectly in our other sites.

A simple solution – aren’t they always?

In the end it turned out to be a very simple path issue. The stylesheet ‘typography.css’, was being included in the header, using the WordPress global array to place the URL dynamically, like this:

href="<?php echo get_bloginfo('template_directory').'/style/css'?>"

We use this for everything on WordPress, but for some strange reason Firefox didn’t like it when we were using it to include any CSS where the @font-face property was being used. Oh Firefox, you’re usually so good to us!

So to remedy this problem, we needed to hard code the exact URL of the style sheet. So instead it looked something like this:

href="http://koodoz.com.au/exact/path/to/css/files/typography.css"

Cleaning up

It worked. But it’s not pretty, and it’s certainly not practical in such a large website. So we russelled up a good old fashioned PHP constant in the main PHP configuration file to place this in dynamically for us.

Here’s an example of the constant:

define('PATHNAME', '/path/to/css');

And here it is in action:

href="<?php echo PATHNAME ?>/typography.css"

Ah, that’s better.

Update

A quick update on this problem! As Daniel pointed out, the issue is caused by a possible security feature in Firefox that prevents the font from being implemented when being called from an absolute URL. For example, Firefox didn’t like it when we were calling the font from the WordPress get_bloginfo constant because it spits out the absolute URL (including the http://www….), possibly causing Firefox to think that the font is being stolen. Therefore, the new constant that we defined (PATHNAME) worked just fine because it doesn’t include the full URL.