All posts tagged ‘@font-face’

Decoding Web Fonts With ‘What Font’

What Font shows you which font a webpage is using

Designers have been bemoaning the state of typography in the browser since the dawn of the web. However, CSS 3 and the @font-face rule go a long way toward improving your font options. Throw in tools like lettering.js and easy-to-use font services like TypeKit and it’s not hard to turn your site into something from a typography nerd’s fantasies.

The days of only six font choices on the web are, thankfully, well behind us. Now you can choose from hundreds of fonts, whether you embed your own or use a service like Typekit. We see gorgeous typography on different sites everyday and sometimes we’re left wondering, what is that cool font?

That’s why we’re loving the What Font bookmarklet from developer Chengyin Liu. What Font is a little JavaScript bookmarklet you can add to your favorite browser and then, when you want to know which font a site is using, just click the bookmark and hover the text in question. What Font will hover a small transparent overlay with the typeface name (see screenshot above).

To try it out, head on over to Liu’s site and drag the bookmarklet to your browser’s bookmarks bar.

It’s worth noting that you can get the same information from Firebug or the WebKit Inspector, but What Font doesn’t have the interface overhead of Firebug or WebKit’s developer tools — it just does one thing and does it well. Couple the What Font bookmarklet with FontFonter and you can preview your website in your favorite new font in no time.

See Also:

File Under: CSS, Fonts

Dealing With the Dreaded ‘Flash of Unstyled Text’

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

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

The use of custom fonts on the web is finally a viable option for designers.

Browser support for CSS’s @font-face rule is pretty solid — even IE 5 can be wrangled into displaying custom fonts loaded from your server. Services like Typekit, which licenses fonts from well-known font foundries, and free services like Font Squirrel are helping to smooth the licensing issues surrounding custom fonts on the web.

However, while browser support and licensing is getting sorted quickly, there’s still one big problem with web fonts — the dreaded “Flash of Unstyled Text,” or FOUT.

The problem (despite the name, it has nothing to do with Adobe Flash) stems from how browsers render a page: progressively, prioritizing the raw content, then grabbing the stylesheet and then grabbing any external font files. The actual FOUT effect can be seen in the wild, but it varies by browser.

Internet Explorer will load the font file as soon as it encounters the @font-face in your CSS, which minimizes FOUT. However, make sure to put your @font-face declaration above any script tags, otherwise IE will hold the entire page until the font loads.

Safari and Chrome (and other WebKit browsers) hide any text styled with @font-face until the font is fully loaded. This means your styled text content is invisible at first, and then pops onto the screen later, after the font file loads.

Firefox loads all your text normally and displays it using a fallback font. Then, a half-second or so later, that text is “upgraded” when the custom font data is loaded. The result is a jarring font change, much like older, Flash-based font solutions. Mozilla is currently treating this behavior as a bug in Firefox. Mozilla plans to adopt the WebKit-style rendering in the future.

Obviously none of these cases is ideal, and the little loading hiccup, no matter what form it manifests itself in, is noticeable even to the most oblivious of web users.

FOUT sucks. So, what do you do? There are a variety of techniques that can be used to minimize — and even eliminate — the FOUT.

Continue Reading “Dealing With the Dreaded ‘Flash of Unstyled Text’” »