So I’ve wanted to use a condensed, bold Franklin typeface for my site’s headlines since, well, forever. So I bought Fontspring’s fine Franklin Gothic FS Demi Condensed and licensed it for @font-face use for a mere $2.99, an incomparable value.
It looks great in Safari, Chrome, and Firefox, but not so nice in the latest version of Opera, where it resembles the inside-out test monkey in Cronenberg’s “The Fly.” (Okay, okay, it looks like a ransom note, but the monkey simile was more picturesque.)
And this, my friends, is why Typekit exists. Because even when you find a great font that’s optimized for screen display and can be licensed for CSS @font-face use, guess what? There is almost always some glitch or bug somewhere. And Typekit almost always seems to find and work around these bugs. It’s the kind of grueling task designers hate dealing with, and Typekit’s team loves solving.
If this were a client site, I’d switch to Typekit, or try licensing a different vendor’s Franklin, or (if neither of those options proved satisfactory) dump web fonts altogether and use Helvetica backed by Arial instead. But as this is zeldman.com, I’d rather nudge my friends at Opera to look into the problem and fix it. This will make browsing zeldman.com in Opera a somewhat weird experience, but hopefully it will help all Opera users in the long run.
Implementation Notes and Details
I haven’t made an SVG version yet, so the web fonts don’t work in iPhone or iPad.
iPhone and iPad see normal weight Helvetica instead of bold Helvetica, because if I leave “font-weight: bold” in the CSS declaration, Firefox double-bolds the font. This is not smart of Firefox. Fixed via technique below.
In order to match the impact of the previous Helvetica/Arial bold, I boosted the font-size from 25px to 32px. (This also helps smooth the font. Web fonts need more help in this regard than system fonts.)
Camino ignores @font-face and supports the first system font in the font stack, Helvetica Neue (correctly styled bold).
GEORGIA and Verdana, Lucida and (to a lesser extent) Arial and Times New Roman have served us well. For fifteen years, these cross-platform default fonts have been faithful stewards of our desire to read, write, design, and publish web pages. Yet we designers have always wanted more. As far back as 1994, we hoped for the day when we could brand our layouts as magazine and poster designers do, by setting our pages in Franklin or Garamond, our headlines in Futura or Rosewood. And since 1998, CSS2 has provided a standard way to embed any typeface, not just the fab five, on a web page.
In August, 2007, CSS co-creator and Opera Software CTO Håkon Wium Lie wrote CSS At Ten, reminding us that CSS provided a mechanism by which actual font files could be linked to and retrieved from the web. Soon after the article was published, “web fonts” discussions started popping up at interactive design festivals and my friend Jeffrey Veen got the idea for a product that would get web fonts happening without running afoul of inconsistent browser support, multiple format hangups, or type designer licensing agreements and piracy concerns.
Speeding up design acceptance
While browser improvements and web standards alone provided multiple partial solutions, Typekit offered a complete solution that just worked. And the people behind Typekit (including Bryan Mason and Jason Santa Maria) did everything right: they reached out to the type design, graphic design, and standards-based web design communities; they worked with vendor after vendor to offer as many fonts as possible; they spoke everywhere, marketing their venture one lecture and even one designer at a time.
Typekit excited the web design community about type and proved that licensing and hosting web type was a viable business, providing options and convenience for designers and their clients, while bringing new revenue to type designers and protecting their intellectual property.
Typekit is the tipping point
Publicly and truly, I support Typekit because it is getting us to the world of web fonts faster. We could wait indefinitely for type vendors to agree to industry-standard licensing terms and font formats. We could wait far longer for IE, Firefox, Safari, Chrome, Opera, Opera Mini, Mobile Safari, and the rest to support the same font formats. (Currently Firefox supports WOFF and TrueType, Safari and Chrome support TrueType, MobileSafari supports SVG, IE supports EOT, and on, and on.)
But with Typekit, we don’t have to bother our pretty little heads worrying about these inconsistencies, and we don’t have to sit on the sidelines, waiting for all font makers and all browser makers to support a single standard format.
Platforms and performance
Typekit works, and that helps web designers and type designers take “web fonts” seriously. Typekit’s success is even helping to make web designers and type designers more aware of platform problems that can make fonts hideous on various platforms. Georgia was designed for the screen. Garamond was not. Moreover, platforms vary the way they hint fonts (Apple throws out hinting altogether, Microsoft over-hints) and the way they render them (from purely pixellated to at least three varieties of sub-pixel anti-aliasing), making a font’s appearance on a given user’s system hard to predict.
If not for Typekit, we might have had to wait years for most or all type designers to license web fonts. Only then would we have discovered that body text set in anything other than Georgia and Verdana pretty much blows on many Windows OS, browser, and monitor combinations.
Thanks to Typekit, we all know about the problem, and type designers are re-hinting their fonts, and in some cases redesigning them for the screen.
For all this I and all of us can be grateful to Typekit.
They also understand that designers will only use “web fonts” if they have access to the fonts they need. Just as a huge selection enabled iTunes to dominate online music, Typekit’s makers know their service must offer pretty much every good typeface out there—and they are working on it.
Renting versus “owning”
All this said in Typekit’s favor, I have mixed feelings about their product because I’d rather buy a web-licensed font than rent it—and Typekit’s success at establishing the viability of a rental model means that individual type foundries will also rent their fonts—and those who succeed at renting their fonts to web designers may not be inclined to sell.
Of course you never really own the fonts you buy—you simply license their use. So the analogy of owning versus renting doesn’t exactly hold true. But a one-time font purchase as a line item in a design budget is easier to explain and sell to a client than an ongoing rental charge.
Web Standards and @font-face
My other qualm has to do with a preference for pure web standards over product-assisted web standards. I don’t know if my preference is ideological or just the way my mind works (or fails to). But, given my druthers, I’d rather see millions of websites using standard @font-face to link to self-hosted web-licensed fonts than see that same number of fonts using a service—even a brilliant service created by friends for whom I wish continued, deserved, great success. It must be a quirk of mind; there’s no other logical explanation for this preference.
For those who share this bias, possess the properly licensed fonts, and don’t mind using FTP and writing a little code, the CSS @Font-Face Generator by Font Squirrel provides an exceptionally easy way to automatically generate the font formats necessary to take all browsers (including mobile) into account—complete with automated Cufón backup and your choice of best-practice @font-face code strings.
Web designer Joshua Lane, currently best know for doing fancy web stuff at Virb.com, has overhauled his personal site in ways that are aesthetically pleasing and visually instructive.
Like all good site redesigns, this one starts with the content. Whereas the recent zeldman.com redesign emphasizes blog posts (because I write a lot and that’s what people come here for), Lane’s redesign appropriately takes exactly the opposite approach:
There is a much smaller focus on blog posts (since I don’t write often), and a much larger focus on the things I do elsewhere (Twitter, Flickr, Last.fm etc). Individually, I don’t contribute a great deal to each of those services. But collectively, I feel like it’s a good amount of content to showcase (as seen on the home page). And something that feels like a really good representation of “me.”
The great Barry Schwartz based his Goudy Bookletter 1911 on Frederic Goudy’s Kennerley Oldstyle, a font Schwartz admires because it “fits together tightly and evenly with almost no kerning.” Lane inserts Schwartz’s open-source gem via simple, standards-compliant CSS @font-face. Because of its size, it avoids the secret shame of web fonts, looking great in Mac and Windows.
But considered type is far from the redesigned site’s only nicety. Among its additional pleasures are elegant visual balance, judicious use of an underlying horizontal grid, and controlled tension between predictability and variation, ornament and minimalism. Restraint of color palette makes photos, portfolio pieces, and other featured elements pop. And smart CSS3 coding allows the designer to play with color variations whenever he wishes: “the entire color scheme can be changed by replacing a single background color thanks to transparent pngs and rgba text and borders.”
In short, what Lane has wrought is the very model of a modern personal site: solid design that supports content, backed by strategic use of web standards.
New Franklin in Town
There’s a new Franklin in town. It’s TeeFranklin, designed by Tomi Haaparanta for T26. Haaparanta specializes in what we used to call grunge fonts, but you’d never know from his Franklin, which is classic and pure. In terms of available weights and styles (not to mention fanatical attention to detail), Haaparanta’s new font can’t compare to Font Bureau’s ITC Franklin, but TeeFranklin is a nice and clean, and comes in 14 weights, which may be enough. Better still, according to reader Ethan Dunham, it is licensed for @font-face embedding.
Real Fonts and Rendering: The New Elephant in the Room
My friend, the content strategist Kristina Halvorson, likes to call content “the elephant in the room” of web design. She means it’s the huge problem that no one on the web development team or client side is willing to acknowledge, face squarely, and plan for….
Without discounting the primacy of the content problem, we web design folk have now birthed ourselves a second lumbering mammoth, thanks to our interest in “real fonts on the web“ (the unfortunate name we’ve chosen for the recent practice of serving web-licensed fonts via CSS’s decade-old @font-face declaration—as if Georgia, Verdana, and Times were somehow unreal).…
Put simply, even fonts optimized for web use (which is a whole thing: ask a type designer) will not look good in every browser and OS.
Real type on the web. All the kids are doing it. But maybe we’re doing it wrong. After testing several CSS @font-face syntax variants, including one used on this site, Paul Irish says the following is clearly best:
[S]tarting today, Typekit users can pick from dozens of FontFonts, including FF Meta, FF Dax, and FF Netto. Plus, the Typekit service lets you test any of those FontFonts on your page before you publish.
Typekit is just one piece of a holistic strategy for FontFonts on the web. The library should be licensable in a more traditional way too. That’s where WOFF fits in. … Soon anyone will be able to license and download for their website the same professional quality FontFont they use in desktop applications, but crafted specifically for the new medium.
Ellen Lupton is curator of contemporary design at Cooper-Hewitt, National Design Museum in New York City and director of the Graphic Design MFA program at Maryland Institute College of Art (MICA) in Baltimore. She is the author of numerous books and articles on design, a frequent lecturer, and an AIGA Gold Medalist.