Category Archives: CSS

Typekit Hopes to Become the YouTube of Fonts

A new startup is hoping to solve the web’s font problem.

Designers have been bemoaning the state of typography in the browser since the dawn of the web. The current technology for rendering type in the browser without using Flash or other non-standards-based methods essentially limits designers to only six fonts.Of course, we already have some ways around those limits, like sIFR and Cufn, two projects that use Flash and JavaScript, respectively, to embed fonts on web pages from the server side. However, there’s long been a better way to embed fonts waiting in the wings: using CSS.

The W3C @font-face declaration for CSS has been around for some time, but has languished due to two big problems. First, most browsers didn’t support it. But with the latest versions of Safari, Firefox, Opera and Google Chrome all now supporting @font-face, that problem is close to being solved.

It’s the second major problem that’s the sticking point: licensing restrictions forbid embedding fonts via CSS. Unfortunately, the font foundries which create, sell and license fonts have thus far been reluctant to embrace licensing terms that would allow designers to serve fonts legally. The foundries fear that users would be able to pirate the fonts much more easily if the files were published in the wild on the web.

It’s this problem that Typekit, an as-yet-unlaunched web service, is trying to solve. Typekit is the brainchild of Jeffrey Veen, a noted web designer (and former Wired.com engineer and contributor to Webmonkey) who is hoping that Typekit can strike a deal with the font foundries and provide licenses that will allow designers can use them on the web.

Although Typekit’s official announcement is thin on details, it looks as though the company will host the font files, which designers can then license for a fee. From there, the fonts could simply be embedded using the @font-face declaration in a site’s stylesheets.

Sounds prefect right? Well, maybe. There are some possible problems with Typekit’s scenario.

First, there’s the issue of potential downtime. If Typekit’s servers choke (and even Amazon’s S3 service goes down from time to time, so don’t expect Typekit to be any different) all your fancy fonts vanish. Depending on how complex your design is, an outage could turn your site into a garbled disaster.

The other possible problem is that Typekit will require adding “a line of JavaScript to your markup.” Hopefully what that means is that you’ll need to embed a license checking script. But the announcement isn’t clear about this, and some commenters seem to think it means Typekit is planning to use a font replacement system along the lines of Cufn.

Update: According to Typekit’s Jeffrey Veen, the commenters have it wrong.

“Typekit isn’t using any sort of image replacement for rendering fonts on web pages,” Veen tells Webmonkey. “We’re using the CSS @font-face declaration to link to TrueType and OpenType files. We’re using JavaScript to simplify that process and account for various browser versions.”

Ah, yes, various browser versions. At the back of everyone’s mind is the problem of Internet Explorer — Even the brand new IE8 still does not support the @font-face rule. However, after watching the developments come out of Google’s I/O conference it seems pretty clear that the web is moving forward with or (more likely) without IE.In the meantime, Veen says Typekit is taking special considerations to deal with Internet Explorer.

But over time, using Internet Explorer will result in a second tier web experience, since the browser remains without HTML5 and CSS 3 support. Users will start asking why, and one of two things will happen: either users switch to a different browser or Microsoft adds the missing features. Either way, the web wins.

Assuming @font-face support becomes ubiquitous across all browsers at some point, font foundries and Typekit may well find themselves in the same position that the music and film industries are today — fonts will be embedded using @font-face directly, regardless of copyright laws.

Despite the potential problems and complexities, we welcome the impending arrival of Typekit. If it can work around these outstanding issues, it has a good chance of succeeding. If you’d like to be notified when the service is available, head over to the sign up page and add the blog feed to your RSS reader.

Use @font-face Today With Free, Legal Fonts

With the latest versions of Safari, Firefox, Opera and Google Chrome all supporting CSS’s new @font-face rule, you might think web designers everywhere would be rushing to add fancy fonts to their websites. But of course, most aren’t. So why, if designers have been bemoaning the state of typography in the browser since the dawn of the web, hasn’t the recent growth of @font-face support turned things around?

There’s actually another, much more complicated problem with @font-face that stops it from being the panacea for your font woes: licensing.

Unfortunately, the font foundries which create, sell and license fonts have thus far been reluctant to embrace licensing terms that would allow designers to serve fonts via @font-face legally. The foundries fear pirates would be able to steal fonts much more easily if the files were published in the wild on the web.

There are some possible solutions to this, such as third-party middlemen like Typekit. However, involving yet another layer of complexity (and potential failure) to your web stack isn’t anyone’s idea of fun. So what’s a designer to do?

It turns out there are actually some fonts that you use with @font-face today. Font Squirrel, one of our favorite places to find free fonts has an entire section devoted to @font-face compatible fonts.

Two things to keep in mind with Font Squirrel’s list: First, as the site says, “Font Squirrel makes no guarantee that our interpretation of each license is correct,” which means make sure you read it yourself and possibly contact the creator to clarify. And second, some of these fonts are downright ugly.

But not all of them. Designer Francesco Mugnai recently posted a nice roundup of some of the best @font-face candidates from the Font Squirrel collection, including two of our favorites, Museo Sans and Anivers.

Of course, even with legal fonts and decent browser support, @font-face isn’t for every project. However, if you’re sick of Flash solutions like sIFR tired of being limited to only the six fonts found on nearly every PC, Font Squirrel’s list of @font-face compatible free fonts could be the solution you’ve been searching for.

Boing Boing’s Redesign Uncovers the Dark Side of Web Fonts

Culture news site Boing Boing recently tried a daring experiment — redesign its immensely popular website using some largely untested tools of the open web.

Unfortunately for Boing Boing, its ambitious plan resulted in a small disaster.

The team decided to use CSS3′s @font-face rule in its recent site redesign, which would enable it to use a custom font to display its text. However, far from delivering the look BoingBoing was going for, @font-face fell flat on its face; when the changes went live Tuesday, not only were the fonts Boing Boing wanted to use not legally available for the web, the font it settled on — specifically BPreplay — ended up looking terrible for most users.

The result was hordes of angry Boing Boing fans complaining that the new headline font was “ugly,” “an abomination” and “plain nasty.” Of course, the culprit wasn’t really the font, but rather how different it looked depending on which browser and operating system the viewer was using.

Web designers have long been pining for open source tools that would afford them more control over site designs, including the ability to create animations, complex layouts and — probably the biggest wish-list item — the ability to use original typefaces and proprietary fonts in their designs. Many of these things are currently being written into into HTML5 and CSS3, two next-generation open standards for building well-formed web pages. We’ve even praised CSS3′s font-face rule and talked about how you can legally use it today.

The problem is that while modern browsers, like the latest versions of Safari, Firefox, Opera and Google Chrome, all support @font-face, the Windows XP operating system often doesn’t have anti-aliasing turned on by default. The rule, which is still part of CSS3′s draft specification, is also not supported by any version of Internet Explorer. So, as cool as your font might look when properly anti-aliased, on Windows XP it looks, as Rob Beschizza, head of Boing Boing’s redesign puts it, “like ass.”

Beschizza, who like many Boing Boing contributors used to work for Wired.com, spoke to Webmonkey over e-mail shortly after the redesign launched and after the feedback started pouring in.

For those using Windows Vista or Mac OS X, Boing Boing’s redesigned headline fonts looked just fine. Indeed much of the experimentation so far with @font-face is happening on designers’ blogs and portfolios — sites where the audience is likely to be using a modern browser and a modern OS.

If your audience is limited to people who live on the web’s cutting edge, then @font-face works pretty well.

However, for sites like Boing Boing, which has much broader audience, Windows XP and older browsers are still a significant portion of daily traffic. And while browsers that don’t understand @font-face (such as Internet Explorer) were fed a typical web font, in this case Verdana, the combination of modern browser and older OS proved disastrous.

But even practical issues like improper font rendering weren’t the only problem Boing Boing faced trying to use @font-face.

The font BoingBoing ended up using, BPreplay by the design group backpacker, wasn’t its first choice, but rather, because of licensing issues, its only legal choice.

“Our first pick for that headline font was VAG Rounded, which Mark (Frauenfelder, co-founder of Boing Boing) had used in his first mock-ups for the design,” says Beschizza, but the foundry didn’t offer a license for web display.

In fact the design team went through a whole list of font choices before they found one that was legal and fit their design.

Given the outcome, it isn’t hard to see why some foundries don’t want to license their fonts. Forget about @font-face making the actual font files available for download — if the fonts look terrible, no one will want them anyway. In fact, the foundry that makes one font Boing Boing tried to license cited appearance as the main reason they were declining to license the font.

So does that mean there isn’t going to be a way to use @font-face until Windows XP is a dim memory? Well you could always use JavaScript to detect the operating system and selectively applying @font-face to an OS that can render it. That (among other things, like licensing complexities) is one of the potential problems startups like the TypeKit project are hoping to solve.

Of course there’s always another option — just ignore Windows XP users. For smaller sites that may be a viable option, but for sites the size of Boing Boing the only real alternative is to do what Boing Boing did — revert to good old Helvetica and call it day.

Eventually web fonts will work, but for now they remain well out on the cutting edge. So, if you’re working on a large site, tread with care.

Typotheque’s Web Fonts Rock, But Old Machines Can’t Learn New Type Tricks

Font foundry Typotheque has introduced a new web font system that gives web authors a new set of font embedding options for their website designs. However, as cool as Typotheque’s new tools are, they can’t overcome some larger problems with the @font-face rule in CSS and the state of type on the web in general.

Typotheque, a Netherlands-based font foundry, recently unveiled a set of web licenses and an easy cut-and-paste solution for web developers looking to take advantage of the CSS3 @font-face support in modern web browsers. The solution is particular nice because it doesn’t require the overhead of loading JavaScript libraries like some other proposed solutions we’ve covered, such as TypeKit. Typotheque’s system requires only a CSS file and a simple @font-face stylesheet rule.

Also working in Typotheque’s favor is a web-only license, which is issued and controlled by the company, that’s considerably cheaper than licensing the actual font files.

Unfortunately, in the real world, @font-face’s results aren’t always what you expect. As BoingBoingrecently discovered when it tried a redesign using @font-face to embed custom fonts, CSS3′s @font-face rule doesn’t always render correctly on older PCs.

While it’s nice to see font foundries like Typotheque embracing both web licenses and simple embedding tools, the results are decidedly mixed. So long as your site’s users are running a modern OS like Mac OS X, Windows Vista or most Linux distros; and they have modern browsers like Firefox or most of WebKit-based browsers, the @font-face and Typotheque’s new embedding system work wonderfully. The only minor issue is a quick flash of unstyled text appearing when the page loads in Firefox, but that can be addressed with a simple JavaScript workaround.

However, for those users still using Windows XP, embedded fonts are not, by default, anti-aliased and results in jagged, ugly fonts that aren’t going to make you or your visitors happy.

To see how things looked in various browsers, we loaded Typotheque’s Fedra Sans font up in a test page at 72 pixels and then looked at it in various browser/OS combos:

Fedra Sans in various browsers. Click the image for a larger view.

As the image above demonstrates, the results are just fine in Firefox on Mac OS X and Linux, acceptable in IE7 in Windows XP and downright ugly in IE6 on XP. Given the considerable percentage of web users still browsing with IE6 in Windows XP, @font-face clearly isn’t going to work for every site.

Still, for those that just want to experiment with @font-face, Typotheque’s new system is the simplest, cheapest system we’ve tested. There’s even a free month-long trial available for testing purposes. For more details, head over to the Typotheque website.

Review: Typekit Delivers Custom Web Fonts to the Masses

A new service called Typekit is now offering a legal, cloud-based method of using more elaborate typefaces on the web. The service has come out of beta and is serving up its fonts to web designers.

Despite some inconsistencies between browsers (not Typekit’s fault) and a few other quirks, we found Typekit to be a viable option for web designers looking to incorporate custom fonts into their designs.

Typekit is like a YouTube for fonts. Browse through Typekit’s library of available fonts, pick one you like and cut and paste some code into your site. As we noted when we first looked at Typekit earlier this year, the service is one of the easiest ways for web designers to use creative fonts without sacrificing web standards or violating font licenses.

Of course, that ease and convenience doesn’t come without a price. There is a free trial option for Typekit, which allows you to test out the service. But if you’re serious about custom fonts, you’ll want to go with one of the paid options which range from $25 to $250 per year. The more you spend, the more font choices, domains and bandwidth you’ll get.

Typekit arrives at a time when type on the web is at a crossroads. For years, designers have been limited to using only a set of five or six common fonts on web pages. But thanks to new font-rendering tools within the emerging HTML5 and CSS3 standards, web designers now have the ability to use newer, more visually interesting typefaces — and make that type appear more consistently across browsers, operating systems and screen resolutions. Even with these new abilities, intervening forces like DRM, licensing restrictions and varying levels of support from the browser makers have stalled progress, forcing the modern designer to resort to a variety of workarounds and hacks if they want to use these new fonts.

Along with Typekit’s arrival, we’ve seen other promising developments recently, like the move by some browser makers towards adopting a new font format called WOFF which would allow better control over layouts and designs.

To see how Typekit performed in the wild, we opted to try out the free option and see if Typekit was good enough to warrant the expense. The short answer is yes, but with some drawbacks.

Before you dive in to Typekit, it’s important to remember the one very large caveat — Typekit only works in browsers that support the CSS @font-face rule. That means Firefox 3.5 and higher, Safari 3.4 and higher, and Internet Explorer 6 and higher.

While that’s not ideal, the good news is that browsers that don’t understand Typekit’s fonts can simply fall back on a default you’ve defined.

There is another slight problem, though. In some cases, fonts rendered in browsers on Windows XP can look jagged and difficult to read. The problems is that Windows XP often doesn’t have anti-aliasing turned on by default. Of course it’s worth noting that even if you don’t use @font-face, standard fonts will also be jagged on such systems. The difference is that most of the standard fonts are still readable, while in some cases custom fonts become a total disaster.

To get started with Typekit, just create an account and tell Typekit the domain where you’ll be serving the fonts. We were happy to see that Typekit will support the localhost domain for testing purposes, something many online services and APIs overlook.

After your account has been created and your domain set up, Typekit will then give a snippet of HTML to include on your site. The code simply loads Typekit’s JavaScript library; all you need to do is paste the HTML in the <head> of your site.

Now it’s time to pick some fonts. Typekit’s range of fonts depends on the amount of money you want to spend. For a trial account, you’ll have just under 70 fonts to choose from. The “personal” library ($25/year) has roughly 230 fonts and the full library ($50/year) nearly 300.

The Typekit font-browsing interface is very well designed and offers some nice tools for choosing a good font — like a live preview of the font and numerous size previews for judging readability.

Typekit’s live preview tool with custom text. Click the image for a larger view.

Once you’ve selected a font, you’ll need to configure it for your site. The Typekit editor lets you control which CSS selectors your custom fonts will be applied to, which weights and styles to use, and what font to fall back on for browsers that don’t understand @font-face.

If you’d rather apply a font to all elements on your site, you can define your own custom font-family rules in your CSS file, for example h1 {font-family: "tenby-seven-1"} would apply the Tenby Seven font to all headlines on the site.

Typekit’s editor tool for customizing fonts. Click the image for a larger view.

The next step is to publish your font, which then makes it available on your domain.

The results looked great in our testing, especially in Safari 4, which seems to render type a bit thinner than Firefox on the Mac. On the Windows side, the results were roughly the same between browsers that supported Typekit.

One thing that seems unavoidable with @font-face, whether it’s through Typekit or otherwise, is a brief flash of unstyled text. It’s annoying, but for now there doesn’t seem to be anything you can do about.

There are some other drawbacks — the need for JavaScript and the additional data that increases page load times — but so long as you’ve already accepted @font-face‘s shortcomings, Typekit makes the process of using it simple and easy. Other possibilities for broadening your type selection includeTypotheque and a new service Kernest.