Real Fonts on the Web: This Time It's Actually Happening

A year ago we wrote a post advising typographic patience. Craft within the dozen web-safe faces, keep the markup clean, and watch for the thaw. We flagged Safari’s quiet @font-face support as the flicker worth watching.

Consider the watch rewarded. Firefox 3.5, weeks from release, ships @font-face for regular font files. Opera has committed. And this week Jeffrey Veen announced Typekit, a service designed to solve the problem that technology alone never could, which was never rendering but licensing. For the first time in our working lives, real typography on the web is a planning question rather than a wish. Time for a proper update.

Why the freeze was never technical

The capability has existed, embarrassingly, for a decade. @font-face entered the CSS specification in the nineties, and Internet Explorer has supported a proprietary variant since version 4. What killed it was the business layer.

Fonts are licensed software. @font-face as implemented delivers the actual font file to every visitor’s cache, where it can be trivially copied. The type foundries, whose entire revenue is licensing, reasonably declined to permit their catalogs to be distributed to the world for the price of one license.

Browser makers, foundries, and designers spent ten years in a standoff, and the dozen system fonts were the demilitarized zone. What has changed is movement on both fronts at once. Browsers are shipping the technology regardless. And, the genuinely new part, service models are emerging that foundries can live with.

The landscape, mapped honestly

• Raw @font-face with commercial fonts: still a minefield. The browsers will render it. The licenses almost universally prohibit it. Check the EULA of the brand typeface your organization licensed for print and you will find, with near certainty, that web embedding is not among the granted rights. Deploying it anyway is a compliance problem, and institutional clients especially should hear that plainly before an eager developer ships it.

• Open-licensed faces: the immediate path. A growing catalog of genuinely free, embedding-permitted fonts exists, and the best of them are respectable work. The catalog’s depth is uneven, strong in workhorse sans faces and thinner in refined text serifs. But for headlines and display use, a well-chosen open face deployed via @font-face is shippable today to Safari users and, within weeks, Firefox’s. This is where the interesting experiments are running.

• Hosted services: the likely mainstream answer. Typekit’s announced model serves fonts from their infrastructure, licensed for web use through subscription, with technical measures that give foundries enough comfort to participate. It is the bridge design the standoff needed. Veen’s credibility with both designers and vendors makes this the announcement that moves the market, whether or not Typekit itself ends up the winner. Expect competitors. Expect foundry participation to grow. Expect ‘web license’ to become a standard line in font EULAs within a couple of years.

• IE’s parallel universe: real, manageable. Internet Explorer supports embedding via its own EOT format rather than raw font files. An annoyance meaning cross-browser deployment needs both formats. Tooling exists, and services like Typekit will handle it invisibly. Hand-rolled deployments must remember it or silently skip the majority browser.

The craft cautions, before enthusiasm ships anything

New capability, familiar duty of care. File weight is real. A font family with weights and italics can add hundreds of kilobytes to first page load, the kind of tax our performance conscience exists to police. Subset what you deploy, since headline use rarely needs four weights, and treat each added face as a budget line.

Rendering quality varies by platform. The same font that is elegant on a Mac can render brittle on Windows, where hinting quality decides everything. Test on real machines before falling in love.

And fallback stacks still matter, more than ever. Some visitors will not get the custom face: older browsers, slow connections mid-load. The CSS font stack behind it must be a considered design in itself, sized and spaced so the layout survives the swap. The discipline from last year’s constraint piece remains the foundation: hierarchy, measure, leading. Custom faces are seasoning on a dish that must already be cooked.

What we’re testing on our own headline treatments

A brief report from the workbench, since positions should carry evidence. We have been running an open-licensed display face on an internal project’s headlines for three weeks, via @font-face with the conventional fallback stack behind it. The findings preview what your team will meet.

The Mac rendering is simply lovely. The design intent, delivered. Windows rendering ranges from acceptable to visibly brittle depending on the face’s hinting, confirming that font selection for the web must audition on Windows first, not last.

Load behavior introduces a wrinkle print never had: a brief flash as text renders in the fallback face before the custom font arrives. Disconcerting on slow connections, invisible on fast ones. It is a reminder that the fallback stack is a design surface, not an afterthought. We now size and space ours so the swap barely registers.

And the subset discipline is real. Trimming the font file to the character set and weights actually used cut its payload by more than half. None of these are reasons to wait. All of them are reasons to prototype before promising a launch date, which is the house method for every new capability.

What to do this quarter, by role

For design teams: begin the brand-typography-on-web conversation now, ahead of the capability’s mainstream arrival. Inventory what your brand’s licensed faces permit. Shortlist open-licensed candidates that harmonize with the print identity. Prototype a headline treatment behind a feature flag and test it on real hardware.

For brand owners: when the licensing renewal conversation next happens, ask about web rights. The foundries are drafting their answers this year, and institutional customers asking early will get better terms than institutional customers retrofitting later.

For everyone: keep the markup semantic and the typography in the stylesheet, exactly as we advised when this was still a bet. That discipline is what makes adoption, whenever you are ready, a CSS edit rather than a project.

A closing note on pace. We would guess eighteen months to mainstream viability: browser share catching up, services launching, licenses modernizing. That is soon enough to plan for and far enough not to panic about. Our 2008 advice was patience plus craft. The 2009 revision: preparation plus craft.