Superb article, I’ll definitely consider this when implementing web fonts.

Nice.

Thanks for this great article, Richard! WebFont Loader is perfect JS library I was just looking for …

I had never heard of the WebFont Loader, but it is a really good idea. I will definitely read more about it.
Thanks for the tip Richard.

Excellent article, never heard of this. 24ways is definitely of to a great start.

Two great tips (including yesterday’s) Implemented in two mins make for a fantastic user experience .

Why is it the authors here do so well in our industry … oh yes I know…

Thanks Richard

Awesome article. I have just started using self-hosted webfonts. This article will definitely help me ensure all users have the same experience regarding fonts. Thanks.

I just tested it on an old project’s pages which had this disturbing issue, it works perfectly :-)

Brilliant solution. Thank you!

I would love to propose this solution to any client who cares about FOUT more than an additional HTTP request, and a 13K JS file.

Nice but no JS = no @font-face?
=(

great tip here. now if only i could get all the designers to use web fonts…

Great information, I’ve been toying with font replacement on several websites lately and it is annoying how the major browsers just don’t act uniformly. I will for sure start trying to implement this as a standard. Thanks for the great writeup!

I’m working on a new theme for my wordpress-powered blog and I want to make it typographically appealing. This is exactly what I need so that I could use those WebFont that I been wanting to use. Thank you.

Hmmmm… I might use the javascript events to write a cookie or client side storage flag and only display the font-face typeface on the 2nd page load. I’d actually prefer that to a switcheroo of any form… Webkit’s or firefox’s; both feel like spasms to me.

Cool write-up, Richard. :) thanks!

What, no comments? This post has been up for hours!

The whole way through the article I had this idea that I wanted to share in the comments, and then you chucked it in there at the very end. Very “one more thing”- esque :-)

Regarding the FOUC vs. nothing-then-show dilemma, I think the option that involves the most work will be worth a try. Sticking to displaying the text while we’re waiting for the font(s) to download, and styling it so there’s no reflow of text etc. And possibly even do a fade transition from one font to the other.

Any other pros or cons?

This is a really nice, useful write-up, as we are just starting to utilise web fonts. However (and forgive me if I am mistaken about this), it would be even nicer if it worked with the CSS @font-face declaration, giving you some non-JS backup. Can this be done here?

Hope I don’t sound TOO negative about the article, as it provides a very useful answer to the ‘evil’ (in many people’s eyes!) FOUT :)

But no @font-face action with JavaScript turned off? I can see though how it would be a favourable solution when FOUT is particularly glaring. Thanks for the tip off about this script.

Ahhh, 24Ways – best thing about Christmas! (whilst stuck at work at least…)

This is a great snippet to roll into my starter files. I wonder if this could be put onto the to-do list of Modernizr? Marking support / status as a JS modified CSS class on the opening HTML tag is a really neat way of doing things.

Regards, Karl

I had no idea about this script. How fantastic that we can decide upon the behaviour of loading our fonts, and even extend it. This will certainly be making it in to my boilerplate along with Selectivzr and Modernizr. This was an eye opener, and a nice introduction. It would have been nice to of seen some of the other features that can be achieved, however I will be investigating and playing with these. Great article, thanks.

Wow! Such a great and useful article!

I will for sure consider it for my future website design project if I have to use web fonts! Such a life-saver!

Thanks for sharing! :)

Ahh, a very useful solution I was not even aware of. Fantastic. Will definitely be putting this to use in my web projects.

Thanks for a great and informative article.

Phil

Brilliantly succinct and well-explained. Nice work, Rich!

To avoid making fontface dependent on js, just apply a .nojs to your body and remove it via js asap.

Then add to your css a rule forcing the fontface:
.nojs h2, .nojs p { visibility: visible; }

This way you fallback for the FOUT version, but with no js it’s kinda of acceptable, no?

I loved Web Font Loader and confess never heard a thing about it, but I missed the Progressive Enhancement part, why not check if we have support to JS so we load Font Loader, otherwise just load the .css with @font-face declaration, I think that’s a better approach, isn’t?
December really is the month of learn new cool web stuffs.

I always felt like FOUT was something that only bugged me. I tip my hat to this article.

I can’t believe that I never knew about this! Excellent stuff.

Just use the font face generator. Works without JS and on all popular browsers : CSS only.
http://www.fontsquirrel.com/fontface/generator

If you are worried about the @font-face not working without Javascript, just wrap your old CSS link tag in noscript tags.

The automatic implementation in just another reason why I love Typekit!

What an awesome way to take control of FOUT – this is definitely going into my projects by default!

Hmm… I like the idea of this but whether it’s actually a good idea to alter the default behaviour of someone’s browser, I don’t know.

A great article, playing around with css3 and experimenting with web fonts – this is a good way to create a good standardised UX. I’m going to implement this in a project I’m working on right now.

Cheers.

Excellent article. I was not aware of the existence of this JavaScript library, nor have I ever thought about the possibility of detecting when a font has finished downloading.

Thanks.

Regarding the no JavaScript situation, I never said not to include a regular HTML link to the CSS file – yes you really should do this. As Nathan said in the comments you could wrap this in noscript tags, but it’s not really necessary to do so.

Perfect – thanks.

Thanks for sharing. I already try to play with Google Font API and it’s very simple to use… But for large projects or ecommerce websites I would advise not to use this technique because it slows down (a little) the page loads, which can lead to a lower rate of conversion

I really like the idea of being able to style the fallback text to minimise reflow.

I don’t agree with the notion of changing a browsers default behaviour though.

Whether FOUT is acceptable or not should not be decided by the designer, but by the user. Some users might find it very disturbing, while others might need it because downloading large fonts over a slow connection would make their browsing too slow otherwise.

Therefore it is a good thing that browsers behave differently, although preferably all browsers should have a setting to let the user control the behaviour.

Nice article, txs.

In both Chrome 8 and latest Chromium 10 build, myself and a friend clearly see the FOUT happen on your Safari test page (http://24ways.org/examples/2010/using-webfont-loader/safari.html). That surprised me. Can you/anybody please confirm and hopefully explain why this happens? Webkit should not do the FOUT

I guess that’s FOUC (Flash of Unstyled Content), not FOUT. Anyway, I guess both pros and cons arguments are powerful enough.