There’s been a lot of buzz lately about Responsive Web Design, and in particular about CSS3 Media Queries. When our CEO recently asked me to make our site easier to view on his mobile phone, I jumped at the chance to retrofit our fixed-width layout using these new techniques.
“On the skillset side, what you’ve got to do as a young person entering the field, is really equip yourself with some basic development skills. You have to be able to understand HTML and CSS. You have to know what JavaScript can do and what it can’t do. You don’t necessarily have to write cool JavaScript transitions, or even in CSS, but you’ve got to know what you can do in each. And you’ve got to be able to design so that if you have a more adept coder working with you, they know you know what you’re talking about.”
– Roger Black
Did you know that if you declare a custom font using @font-face, the browser will try to fake the bold and italic styles if it can’t find them? This is a clever little feature that avoids a scenario where a themer specifies a font and is then confused that bold and italics don’t work, but it can be very confusing if you actually have a bold or italic version of the font. In this article, I’ll walk you through how to properly load your font files to avoid the browser’s faux-italic and faux-bold styles.
Recently, twitter was buzzing with news of a CSS technique called optimizeLegibility that enables better kerning and font ligatures. It’s enabled by default in Firefox above 20px text, so you may have already seen it in action. I’d noticed the effect on my Talk Like Warren Ellis site (warning: possibly not safe for work language). I happily added it to my stylesheets, and was pleased to see the effect start working in Safari and Chrome as well. However, when I created the new Metal Toad site, it wasn’t working.
After running some tests, I found out that optimizeLegibility and @font-face don’t work together. I was able to verify that no matter how I tried to load the font using @font-face, even when linking directly to the .otf file, optimizeLegibility had no effect. But the instant I switched to a local copy of the same font, it works just fine. This is very disappointing, as @font-face has always been presented as working the same as loading native fonts, but in this one instance, they don’t work the same at all.
I just wrote the following for our marketing team to understand how to sell font solutions to our clients. If you have any feedback, I would love to hear it in the comments section!
When a client’s design calls for a custom font in the headlines, there are a variety of solutions we can recommend, ranging from sIFR to image replacement. Each solution (detailed below) offers advantages and disadvantages, so the correct choice may vary from client to client. In general, however, @font-face will provide the best long-term solution and ease of development.
CSS3 adds the ability to serve a custom font from the server. It works beautifully, and is well supported in modern browsers*, including IE6+, FF3.5+, Safari 4+, and Chrome 4+. This is the way custom fonts should be handled. That said, there’s one barrier to adoption: Since the font is hosted on the server, you must have a font that is licensed by the foundry (the company that made the font) for web use. There are many free, open-source* fonts available, and a growing library of fonts that can be licensed* directly from the foundry. The cost for a web license (which is frequently separate from the regular cost of the font) ranges widely depending on the foundry.
We encourage our clients to use this method, despite the extra cost, as it is legal, accessible, requires no extra development time, and is the most future-proof solution. Compared to @font-face embedding, every other solution listed here will cost extra (in the form of development time). By purchasing the font license, they are supporting the foundry that made their font, and making their website more adaptable for future edits.
Additionally, for any advanced font styling such as gradient fills, drop-shadows, glows, backgrounds, etc., @font-face is the only solution. You simply cannot recreate these advanced CSS styles on dynamic headlines through sIFR or cufón.
Pros: native font rendering, accessibility, graceful degradation, and advanced font-styling through CSS.
Cons: must use an open-source font, or purchase a license for a commercial font.
Cost: just the cost of the font license. no extra development cost.
Typekit is essentially a hosted version of @font-face. It handles the font licensing and embedding for you, in exchange for a subscription fee. As long as the font(s) the client wants are available in their library (which is pretty large and incorporates several large foundries), this is a very good solution for a very reasonable cost, which could be rolled into the ongoing budget for hosting. The only real downside is that it requires javascript and since it’s a hosted solution, you’re relying on another company’s uptime. I haven’t heard of any issues with Typekit’s uptime, but it’s worth noting.
Pros: handles all the @font-face embedding and licensing for you. Likely cheaper than a license direct from the foundry.
Cons: requires javascript and yearly subscription fee. if typekit goes down (not likely to happen), then the client’s fonts are unavailable.
Cost: depends on website traffic – ranges from $25 to $99/year
sIFR is a dynamic flash-replacement technique which uses javascript to target certain headlines on the site (eg, all H2s, or all H4s in the sidebar). It reads the text, calculates the dimensions the HTML headline would have occupied, and replaces it with a flash movie that renders that headline’s text in the client’s font. This was the most popular method before @font-face came along, but the project is dead in the water now, and hasn’t been updated since October 2008. It’s difficult to implement, though it’s still a decent solution due to the built-in graceful degradation – users without Flash or JS will see the regular HTML headlines, not a broken flash movie. This is also the only dynamic solution that doesn’t require a license from the font foundry.
Pros: graceful degradation, widespread flash adoption, and legal to use with any font.
Cons: complicated and limited. Basic text replacement works great, but more complicated things like nested styles within the headline are difficult or impossible. Project is no longer being developed, and is poorly supported.
Cost: At least 3 hours of front-end development PER headline style, and further QA, since the site now has to be tested with and without flash.
Intended as a replacement for sIFR, cufón uses javascript instead of flash to dynamically replace headlines. It’s easier to set up, but has some serious accessibility concerns, and may not be legal to use without a license from the foundry – and if you have a license, you might as well use @font-face instead.
Pros: less complex than sifr
Cons: accessibility concerns, and since the font isn’t embedded in flash, it may not be legal unless you have a license from the font foundry.
Cost: At least 3 hours of front-end development PER headline style, and further QA, since the site now has to be tested with and without javascript.
Using CSS, we replace individual headlines with images containing that headline set in the client’s font. This solution is time-consuming and difficult to edit, but works well on sites with a small number of headlines that don’t need to be edited very often.
Pros: gives the client exactly what’s represented in the comp.
Cons: requires lots of image production time to create every headline image, and corresponding CSS production time to write code to replace all those headlines with their images. Making edits in the future is difficult, because someone will need to make a new image and edit the CSS. Likely impossible to implement in a dynamic CMS like Drupal.
Cost: 10 minutes per headline, minimum.
This isn’t really a solution, since it doesn’t use the client’s font. I’ve just included it for completeness’ sake. This approach means that we ignore the custom fonts and use one of the limited set of “native” fonts instead. In practice, this means using Arial for sans-serif fonts and Georgia or Times New Roman for serif. If the client’s font isn’t very distinct, then this can be a good choice.
Pros: requires no development time at all.
Cons: does not use the client’s font.
Cost: none.