August, 2009

Internet Explorer 8 comes with two different rendering engines. “Standards Mode” (they use the term loosely) and “Compatibility Mode”. I’m not going to debate the reasoning behind their choice to ship the browser in this form, smarter people than I have already beaten that horse to death. The problem I have with it is that by default IE ships with a setting that makes anything on your LAN show up in compatibility mode. The button to switch to standards mode isn’t displayed, and worst of all, there is nothing that tells you it is IN compatibility mode.

I recently discovered this when, after carefully testing a site in Internet Explorers 6, 7 and 8, I committed the release to the SVN repo and published it to the staging server. A quick test showed IE8 issues that weren’t there on my local version. Turns out the problem was this default compatibility mode setting. You can turn it off by going to “Tools > Compatibility View Settings” and unchecking the “Display intranet sites in Compatibility View” option. They did this to ensure old intranets are compatible with IE8 out the box, but in the process put every web designer in the awkward position of not knowing their site is broken until they upload.

Internet Explorer 8 isn’t all that bad. It does a pretty good job of fixing the (not so) little things that drove us crazy in previous incarnations, but it’s far from perfect. In the very likely event that you need to code some IE8 specific styles I recommend using conditional comments. In this case I needed one set of modifications for IE6, 7 and compatibility mode 8 (which mostly behaves like IE7) and another for IE8 specifically. To achieve this I used the following code:

<!--[if lte IE 7]><link rel="stylesheet" type="text/css" href="css/ie.css" /><![endif]-->
<!--[if IE 8]><link rel="stylesheet" type="text/css" href="css/ie8.css" /><![endif]-->

It uses one stylesheet for everything less than 7 and another for IE8 specifically. Works like a charm, hopefully until IE9 comes along.

I can’t count the number of times I’ve had to explain to clients that their beloved logo font simply cannot be used on the web. I explain that if the visitor doesn’t have the font you want to use installed then they can’t see it. Most of the time they are shocked that this is the case. And they should be shocked. It’s absolutely horrible that we have to deal with these limitations.

Technically it has been possible to use any font you choose through several existing techniques (plain old images or Flash/JavaScript/Canvas trickery like sIFR and Cufón). They all have limitations of varying degrees and body font choices are still limited to the usual suspects. So why is it so hard to use fonts on the web?

Copyright

The main issue is one of font copyright. Fonts are expensive. Making a font takes lot of time, dedication and talent. Font designers deserve to be paid for their incredible work. If you send the font over the internet when you visit a website it doesn’t take long to figure out what’s going to happen.

Font Delivery

The copyright issue had stopped the development of viable alternatives to Microsoft’s (ancient and proprietary) EOT format. Finally however, both Webkit and Mozilla (Safari/Chrome and Firefox) support the @font-face CSS attribute. Making it possible to create an all-browser encompassing font delivery mechanism.

Enter Typekit

The clever peeps at Typekit have managed to fix both problems in one fell swoop. By working with the type foundries directly, they have managed to gain licenses to distribute fonts over the web. They’ve also taken great pains to obfuscate the fonts they are distributing. More importantly for us lowly web designers, they’ve made this stuff ridiculously easy. Choose the fonts you want (236 options as of right now), get a snippet of JS and Bob’s your uncle. All the fonts are compatible with Firefox 3.5+, Safari 3.1+ and IE 5+ (!).

I just got my beta invite and am going to be reworking both this site and ActivElement to use my newly acquired library. Can’t wait to get my font on.