On Beyond Zebra was always one of my favorite Dr. Seuss books: an alphabet of new, imaginary letters and the fabulous beasts whose names they were invented to spell. This week, I finally decided to figure out what this new-fangled
@font-face CSS property for websites was all about, and I’m feeling very much as if the old alphabet has suddenly expanded into uncharted territory. If you’ve visited Via Negativa or any of its sister sites in the past few days, you might have noticed some of the results: a new header font here, a new header and description font at The Morning Porch, new headers and headings at Moving Poems and the Moving Poems forum blog, and a new base font at the Woodrat Photoblog.
You’re probably going to be seeing a lot more of this kind of experimentation around the web in the next few years. Here’s why. Until recently, web designers have been limited to a very small number of fonts that are compatible with all browsers, and a few of them, such as Comic Sans and Impact, kind of suck, which narrows the field even further. You can of course introduce fancy fonts in image form, but the problem with using images rather than text is that you are basically saying “fuck you” to the visually disabled, who rely on screen readers to access the web, as well as making yourself less visible to search engines. (I am continually baffled and irritated by literary magazines that use JPEGs for all or most of their textual content, but that’s a rant best saved for another time.)
The @font-face method is one solution that’s gained a lot of traction over the past year. Check out “The Essential Guide to @font-face” from Six Revisions, which I just discovered this evening (sure could have used it earlier in the week). As they explain, it’s not simply the CSS property itself, but a particular syntax for it that has enabled webmasters to overcome what might otherwise seem like a fairly daunting challenge: the fact that you have to reference four different font formats to accommodate all browsers.
Of course, we can’t possibly expect all the browsers to play nice and agree on a given solution! That would just be unreasonable.
Instead, all the major browsers have decided to go their own way with font formats that they choose to support.
- Internet Explorer only supports EOT
- Mozilla browsers support OTF and TTF
- Safari and Opera support OTF, TTF and SVG
- Chrome supports TTF and SVG.
Further, mobile browsers like Safari on the iPad and iPhone require SVG.
If this is beginning to sound like a huge pain in the ass, relax and do what I did at first: head over to Google Web Fonts. Google takes care of all the complicated stuff for you, and using one of their free fonts reduces the load on your server compared to uploading the font files to your website. To experiment with it, stick the line of code they supply for your chosen font in the head portion of your site, and substitute the name of the font for whatever you want to try replacing in your stylesheet. If you’re the cautious sort of person who likes to read a tutorial first, another one from Six Revisions, “A Guide to Google Font API,” covers all the essential points in a little more detail than Google’s own introduction.
If you’re on WordPress.com, by the way, I believe you can only use Google web fonts with the paid CSS upgrade at this point. Although you don’t have access to your theme’s header file, you can put something like
in your stylesheet and achieve the same effect. Or you can use Typekit via the link-up provided in your site’s dashboard. They do have a few free options, I gather, but for the most part they’re a paid service with annual fees to use proprietary fonts. Which kind of takes all the fun of it, in my opinion.
According to Six Revisions, “The Google Fonts API … neglects to include an SVG version so there is currently no support for mobile devices.” I don’t know that I’m hugely concerned whether people accessing my sites on small screens have access to prettier typography; the fall-back fonts ought to do well enough. However, Google web fonts are still fairly limited in number, so I do recommend checking out the much larger trove of free fonts at Font Squirrel as well. (Thanks to Elizabeth Enslin for tipping me off about them earlier this week.) I used their kit for a public-domain font called Goudy Bookletter 1911 over at the photoblog this afternoon, and the process was painless: just a little more code to paste into the stylesheet, and some files to upload to my WordPress theme folder.
In each case, of course, introducing a new font has prompted me to tinker with the design as well. While this hasn’t resulted in any major changes at this blog yet, it did result in, I think, some dramatic improvements at the Moving Poems sites, where I may end up not keeping that crazy header font — Slackey, by Sideshow — but feel kind of fond of it now, since it was my very first experiment with this new approach to web fonts.
As I’m sure I’ve mentioned before, self-publishing is a habit that started when I was a kid, and my brothers and I put out a quarterly nature magazine. We were part of the Xerox revolution, boys and girls, and it was totally analog! Our articles were typed, we drew the illustrations in pen and ink, and I taught myself calligraphy to do the article headings. Despite devouring a pile of books on calligraphy and type, however, I didn’t keep up with the hobby, and for a number of years in my 20s, virtually the only fonts I composed in were whatever monospaced monstrosities WordPerfect used pre-6.0. MS Word was a huge improvement, with dozens of fonts to choose from. Going from Word to the web, with just a handful of usable fonts, seemed like a step backwards. To this day, there’s a great sameness to the way the web looks, even outside the padded cells of Facebook. But if this @font-face method catches on the way I think it will, the web is about to become a lot more eccentric and diverse.