
It’s almost possible to feel the wave of euphoria rolling around the Internet that’s been generated by the arrival of Web fonts. Finally, website designers can unshackle themselves from the limited range of fonts that’s available once you aggregate down the common typefaces on Windows, Mac, Linux and so on.
I can’t be the only one who sighs in desperation each time the words ‘font-family: Helvetica, Arial, Geneva, sans-serif;’ are keyed into a stylesheet.
When you read the marketing pages from suppliers of Web fonts and font delivery services, you get the impression that with just a couple of lines of code you can transform a site – with no hassle; all the issues taken away from you. The reality is somewhat different: there are actually quite a few gotchas, some of which are easy to miss if you’re not testing thoroughly.
You can’t just take any old font and slap it on your website. Fonts are bound by a usage agreement – most fonts aren’t licensed for Web use. Proceed with care if you’re going to host a font on your own website. Speaking of which…
If you decide to host fonts on the website itself, it’s foolish not to consider bandwidth requirements. If you load up (the typical) four weights of a font, you could be adding 150KB or so to the initial page load. If it’s a high-traffic website, this alone could change your client’s hosting fees. Add in another family for headings and that’s a serious multiplier of bandwidth.
Fortunately, some very well executed font-delivery networks are springing up – I’m thinking of services such as Typekit, WebInk and the like. These services offer a pretty decent range of fonts and are easy to use. Google even provides a good range of fonts for free, hosted on its servers. These companies take care of all the hosting and licensing issues – you just have to load up the fonts and get on with your life. Or do you?
The first thing to remember is that in some respects using Web fonts is cutting-edge stuff. When font-delivery networks say that their code makes their fonts compatible in IE6 and upwards, for instance, the truth is a little more complicated. It’s worth being aware of some of the potential issues.
In certain circumstances, I’ve seen Web fonts leap around when you refresh the screen – their font widths literally change by around 10%-20%, radically altering the width of a line of text. This is worrying, as I find that some website designers don’t habitually refresh screens when testing – in fact, many test using static tools such as BrowserLabs BrowserCam. Testing in this way will not reveal this particular issue. We raised this with Typekit and received this reply: “This is a bug with IE. It’s inconsistent and unpredictable, so it’s very hard to reproduce or pin down. Unfortunately, because it’s hard to reproduce, we haven’t been able to determine what causes it, or if there’s a possible resolution. As far as we know, it affects all Web fonts, not just Typekit.”
I’m sorry, Typekit, I beg to differ. I took the offending page, changed the fonts to a Google font – and the issue disappeared. I can only speculate as to the cause, though I have seen some blog posts suggesting that this is as a result of how Typekit serves fonts – for security reasons it serves different parts of fonts from different servers and pulls them together on the page.
This isn’t something that happens a lot – but it does happen and it should be checked for.
At this point, we have to note that it’s early versions of IE that play up the most – but this is the real world and IE6, IE7 and IE8 have massive installed bases of users. As much as we’d like to, as responsible website developers we simply can’t ignore them. The solution here is to test live in IE6/IE7/IE8 and IE9 as well as all the other browsers in mainstream use.
A project I’m currently working on has had Web fonts pulled from it at the request of the client. The reason? In some circumstances, Web fonts consistently display in a jagged, raggedy way. And not just ‘a bit rough’ either – so jagged that they can be hard to read. The worst offenders are fonts used in a small(ish) size, of course – but actually many, many fonts can be jagged even when used relatively large. This is because a key factor isn’t just the size – it’s the contrast between the font colour and the page background. The site we removed Web fonts from was a news website, so near-black on near-white was obligatory. In IE6-IE8, we couldn’t get any font to display perfectly under quite a range of sizes. Indeed, we found that the way fonts are rendered on Windows can itself be an issue, regardless of the browser – on a Mac they were often fine.
That’s right, any font. Admittedly, we didn’t test every font in the world, but we did test a couple of dozen fonts which are promoted on the basis of their legibility. I tested fonts from font-delivery networks and Google’s free fonts with the same results. In modern browsers such as Chrome, Safari, Firefox, Opera and IE9 they were fine – in early versions of IE, they were sometimes nothing short of terrible. Legibility trumps design personality every day of the week for me.
The cure? Well, before you use a font, create a testing sheet with the font running in a wide range of sizes, in small increments – and test this in all of your target browsers using the intended colour scheme. Pick the sizes which render the best.
As a rule of thumb, you can also visually eliminate the issue by making your design less high-contrast. So, when you’re preparing a design, using Web fonts for mainly headline sizes without too radical a contrast can be safer for older browsers.
Sure, in the future this won’t be an issue – but today it is. Again, the worry is that website designers won’t test thoroughly enough and simply miss this issue. If you’re developing on a Mac and not testing with a live PC (or a virtual machine) then you’re potentially heading for trouble.
Typekit has an excellent blog on this issue – and some other issues which affect font rendering.
Some Web fonts clip parts of their characters (typically the ascenders or descenders) when displayed in certain browsers. And when I say ‘certain browsers’, you know I’m actually mostly referring to IE – although not exclusively. I came across this issue first with the font Arimo, provided by Google Web fonts. It’s a nice, economical font that leans towards Trade Gothic or News Gothic. You can see by this thread on Google’s own forums that the font clipping issue affects many browsers (and even some applications, when used locally) though it only seems to affect Windows users. And yet this font is highly popular and used on many websites – I can only assume that they’ve not been tested thoroughly.
In CSS, it’s typical to nominate weights as ‘normal’ and ‘bold’ but other weights may be specified and it’s important to match these properly for them to display correctly:
So, if you wanted to use the thin version of a Web font, you’d need to declare it in the CSS in this way:
p {
font-weight: 100;
}
Although CSS and some Web fonts support more than four font weights, Internet Explorer does not. It can only display four weights from one family. Typekit again has detailed information on this issue, including tables which show how different font weights are matched in IE.
It’s probably true that with website development you can never test enough, that testing is probably 50% of development and testing in older versions of IE is 80% of that. Testing font issues isn’t something that website designers have typically had to do and quite frankly it’s an unwelcome overhead. But Web fonts are here to stay and are, on the whole, a good thing.
They bring visual variety and creativity to the most important part of a Web page. But right now, today, they need to be implemented with care, an awareness of the issues – and with a decent amount of time set aside for additional testing.
Peter Labrow also runs a website design blog on his own website. He is a website designer who writes horror fiction in his spare time and has just published his first novel, The Well.
Today, I am giving away Web Design Riches, the ultimate guide on how to run a profitable web design business. Enter your name and email below to get instant access.
Ben (1 year ago)
Brill thanks.
Another common issue I find when working with Web Fonts is that in IE it doesn’t fade out correctly.
Say for example I have a slideshow/banners on the homepage containing Web Fonts, on transition of the slides the web font would look horrible.
I managed to fix this by adding a background-color to the web font.
Thanks for the amazing post.
Peter-Labrow (1 year ago)
Hi Ben – thanks – your fix is logical if not obvious, I think it may well help things out in other circumstances too, I’ll give it a try. Peter
Erik Thomsen (1 year ago)
Great article, glad you recognized that fonts are often too small for the area they are being used. The ideal word to line ratio is about 12 words. This may sound extremely short but studies have shown after that mark reading retention and speed drop off substantially.
Robin Jennings (7 months ago)
I love using different fonts but it is so difficult to get it right.
Great set of tips, an awesome post for typography nerds.