That’s a fancy-lookin’ T you got there.

Typekit is one of the easiest ways to get fancy fonts working on your website. Just sign up for an account, pick a font and paste a few lines of code into your pages. TypeKit takes care of the rest, ensuring that your fonts load and there’s no unsightly flash of unstyled content (FOUT) or other problems.

There is, however, one possible problem with the default way of embedding Typekit fonts. If the TypeKit code fails to load, it can slow down the rest of your site. Typekit avoids FOUT by pausing your page load for a fraction of a second, but if the Typekit script never finishes loading, that fraction of a second can turn into many seconds. While Typekit has excellent uptime, let’s face it, outages happen, and we understand if you don’t want to hang your own site’s fate on another.

For those worried about depending on Typekit there is a workaround — load Typekit scripts asynchronously. The Typekit blog recently put posted an in-depth look at various way to embed Typekit fonts in your pages, including an asynchronous method which won’t slow down your page should Typekit become temporarily unavailable.

The disadvantage of the asynchronous design pattern that Typekit outlines is that it means a bit of extra code in your pages. Most likely a few more bytes in your HTML isn’t going to cause a significant speed hit, but it is something to keep in mind.

See Also:

• Improve Your Website’s Typography With Kern.js
• Dealing With the Dreaded ‘Flash of Unstyled Text’
• Lettering.js Makes Complex Typography Easy
• Typekit Teams Up With Adobe to Offer More Web Fonts

Font startup Typekit introduced an API Thursday that lets web programmers generate kits from the Typekit library behind the scenes.

The company has previously only offered the option of picking fonts and generating kits using the web-based tool on its site. But by releasing an API, it’s giving people the option of building Typekit into their own apps or simply extending the way they use the service.

Writing on the Typekit blog, Paul Hammond says: “The Typekit API gives you the ability to programmatically create, modify and publish kits. It also allows them to fetch metadata about all the fonts in the Typekit library.”

Here are the documentation pages. As you can see, the Typekit API returns data in a few different flavors (JSON, XML and YAML)

There’s an example page set up on Github, and while there isn’t much there yet (just a kit generator for Ruby) we can expect more soon.

If you haven’t yet explored Typekit’s service for including fancy fonts in your site designs, you should. Especially handy is the WebFont Loader, an open source library of scripts that Typekit developed to help eliminate the “flash of unstyled text” that happens when a page loads. The WebFont Loader offers a number of JavaScript events which allow developers more control over when and how their fonts are loaded onto the page.

See Also:

• Typekit Now Offering Custom Fonts For WordPress Blogs
• Review: Typekit Delivers Custom Web Fonts to the Masses
• Google, Typekit Join Up to Improve Web Fonts

Google has announced a new Font API and a collection of free, open source fonts anyone can use in their site designs for free. The Google Font API allows you to embed any of the new Google fonts on your website using CSS.

The fonts themselves are quite nice, with a range of script, serif, sans-serif and monospace typefaces. They can all be used to style text via @font-face. There are only eighteen fonts available — so there’s probably no need for Typekit to worry that Google is muscling in on its territory.

In fact, Typekit has partnered with Google to announce WebFont Loader, a JavaScript library for improving the web font experience. Typekit will also be adding Google’s new free fonts to its collection, so there’s clearly still a lot of love there.

The WebFont Loader is an open source library of scripts that Typekit developed to help eliminate the “flash of unstyled text” page load hiccup that we’ve mentioned before. The WebFont Loader offers a number of JavaScript events which allow developers more control over when their fonts load.

Even though things have been progressing quickly in the world of type on the web, with advancements in CSS, HTML5 and the rise of services like Typekit, inconsistencies in browser support and implementation have stopped some from making the move to web fonts. The new WebFont Loader gives hope to those still on the fence by providing a consistent way to handle what the browser does while the fonts are being loaded.

“The WebFont Loader does for @font-face what jQuery has done for JavaScript,” says Typekit co-founder Jeffrey Veen in an e-mail to Webmonkey. “For people who really care about about the speed and user experience of their web pages, the WebFont Library gives them much more control. It essentially moves us a big step forward in the evolution of fonts on the web.”

Veen also praises Google’s decision to keep its work open source and free.

“Getting fonts technically ready for web use is a lot of work, and using the open source model allows anyone to contribute their expertise to a core set of fonts.” he says.

You can use WebFont Loader with fonts on your own server, with links to the just-announced Google Webfont API, or with your Typekit account.

Google made the announcement at its annual Google I/O developer conference, which is taking place in San Francisco this week.

As for Google’s new Font API, well, it’s so simple its hardly an API. You just need to add a link to Google’s stylesheet in the head tags of your page and then apply that font to some element in your page.

The syntax looks like this:

Then, in your stylesheet, you can apply that font to any body element. For example:

h1 {
  font-family: 'Font Name', serif;
}

Google’s new Font API will work in any browser that supports @font-face (which is pretty much all of them). If the Google fonts happen to strike your fancy, the API is certainly easy to use. If you’re looking for a broader selection, check out Typekit.

Typekit offers Google’s new open source fonts, Veen says, but Typekit also offers access to a library of over 4,000 commercial fonts of professional quality. Typekit is currently the only source offering these high-quality typefaces for legal use on the web.

Disclosure: Jeff Veen is a former Webmonkey editor and a former Wired.com employee.

See Also:

• Dealing With the Dreaded ‘Flash of Unstyled Text’
• Google Chrome to Support the Web Open Font Format
• Review: Typekit Delivers Custom Web Fonts to the Masses
• Use @font-face Today With Free, Legal Fonts
• Review: Typekit Delivers Custom Web Fonts to the Masses

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.

With the new WordPress.com features, you don’t even need to know HTML or mess with any code to take advantage of Typekit.

To use the new Typekit features, just log in to your WordPress.com dashboard and click on the Appearance menu in the left-hand navigation menu. On the Appearance page you’ll find a new option, “Typekit Fonts,” with a place to add your Kit ID.

To get your Kit ID, you’ll need to create an account at Typekit.com and select the free option. From there, you can paste over the code and chose from any of Typekit’s fonts.

Not using WordPress.com? No problem, there are already two plugins that make it easy to integrate Typekit into a self-hosted WordPress blog. If you’re on another blogging platform or custom site you can still use Typekit — see our earlier hands-on review of Typekit for details on how to use Typekit on your site.

See Also:

• Review: Typekit Delivers Custom Web Fonts to the Masses
• Typekit Hopes to Become the YouTube of Fonts
• JavaScript Offers Type Designers Better Choices Than Flash
• The Future of Web Fonts Looking Brighter

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 include Typotheque and a new service Kernest.

See Also:

• Typekit Hopes to Become the YouTube of Fonts
• Boing Boing’s Redesign Uncovers the Dark Side of Web Fonts
• Typotheque’s Web Fonts Rock, But Old Machines Can’t Learn New Type Tricks
• The Future of Web Fonts Looking Brighter

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.

See Also:

• JavaScript Offers Type Designers Better Choices Than Flash
• JavaScript Library Fontifies Your Headlines
• The Future of Web Fonts Looking Brighter