Paul Irish

I'm in Firefox 3.5 and I still see the text styled in the default font for a fraction of a section before the proper font is applied. I even tested your code on my own site and experienced the same problem.

what happens in webkit when it thinks it can get the font, but while getting it, something goes wrong? like the font is corrupted or w/e…

does it then show some sort of fallback or does the text never show up? :x

I call this FOUC as "Flash of Unfonted Content" :)
As for the Firefox, there's a ticket in Bugzilla already: https://bugzilla.mozilla.org/show_bug.cgi?id=499292

I have to pitch in and say I absolutely, whole heartily disagree that FOUT is the wrong way about things. I appreciate you're not saying one is better than another, rather which you prefer.

Here's one page that always catches me out – and because my connection is slow at the moment (crappy ISP) – and more often that not I just give up on the page because it doesn't come down:

http://dl.getdropbox.com/u/43399/fout.png

Ahh, my experience is that, while initiating the download as early as possible will help, the FOUT (or FOFF – Flash Of Fallback Font – as I'm calling it ;) ) can only be totally eliminated by supressing the display of the page until you know that the @font-face font has totally propagated throughout the page.
I am not saying I have figured out the best way to do that, just that it's my belief, based on dealing with a similar problem, that it will prove to be the only totally reliable way.
Anyway: Excellent, thought-provoking work. Thanks to Garrick, too, for the insight.
We're learning!

Rich

Note that the setTimeout is likely to be needed in Gecko too in the future in the original ("remove the node" technique), and the size of the timeout needed is likely to depend on the load on the machine, etc.

If you want to ensure the insertion is "noticed", you probably need to flush layout after doing it.

Geez … all designers want is a wider selection of fonts … little did they realize they're heading for a minefield.

Very interesting post (and so is Steve's).

I giggled when I saw that 'fout' means 'mistake', in Dutch! Apropos :-p

For me: I'm happily ignoring all the suggestions under 'best-practices'. I don't like sub-setting – I *might* need that glyph, one day. The other two, while I understand the 'why', are overkill IMO.

I'm hoping that @font-face usage increases dramatically and that browsers-makers catch up, standardize and optimize – or fix – their handling of font embedding.

Cheers

@stk
I'm using FOFF (Flash Of Fallback Font) instead of FOUT because it amuses me that there is now a font format named WOFF. So we've got WOFF and FOFF.
(It makes me loff, what can I say?) FOUT will probably win out, though.
I'm just a curmudgeon at heart.
Cheers, rich

If you use document.write in the head of the document, you can still have your pages validate:

document.write('<b>:)</b>');

Thanks for taking the jQuery idea I had and running with it. I'm very new to this, but one thing that I like about the way I coded this was that I didn't have to hide all the elements on the page. Maybe you don't either, but the caveat that "The page will not be visible until all content, iframes, fonts, and images are downloaded" does seems like a drawback.

Although my jQuery example (here: http://boxcarpress.com/us/blog/2009/11/05/css-font-face-flickering-in-firefox-somewhat-solved/ ) made the whole disappear before fading in, in practice I'm only doing this to divs with the @font-face text. In other words, all the images are loading with content on the page, then the text fades in with the correct font in place. This gives the visitor time to look at content so that it doesn't seem like something is wrong. Also, on one page where I have a lot of images which will delay load time, I show a loading "spinner" gif to make it clear that more content is coming.

I hope this helps implementation for people who are scared of not showing anything until everything is loaded.

Of course if some future version of Firefox happens to change the behavior here you're still going to stick the user with that 3-second wall of nothing….

@Boris In my jQuery js, just make the first line:
if(($.browser.mozilla) && ($.browser.version < '1.9.2')){
…which would limit this to versions prior to FF 3.6. The point is you may limit the scope however you may like (although FF 3.6 beta and 3.7 pre-alpha still show FOUT). There is no perfect way to load the page, but this is a slight improvement over the text re-formating in front of every Firefox user (to me anyway).

doesn't work for me

You should check out TTFGen. http://www.ttfgen.com. It auto generates images from TTF files and CSS parameters. there's also a wordpress plugin…

Maybe I'm smoking crack, but there may be two (only) slightly more elegant ways of handling this:

Use font-size-adjust. It won't stop FOUT, but it will make it much less jarring to the user. I haven't tested FF's implementation, so I don't know how reliable it is. I also don't know how well it's supported in other browsers.

Use Javascript to detect the actual font-family applied to a chosen element. Honestly, I have no idea if this will work, but it's something I've been meaning to try.

Ideas:

Test the theory. See if Gecko accurately reports the *actual* font-family applied to the element, regardless of what it intends to do once the first-priority font is downloaded. I assume this is true since Firebug can accurately tell me the effective font-family for any element.

Proposed test:

Configure development web server to severely limit bandwidth for fonts.
Clear browser cache.
Run test page with similar JS w/ jQuery (I know you want a more general solution than jQuery, but I'm brainstorming here :)) and watch the fonts and console closely:

(function() {
  var element = $("#someid"); // Grab an element to inspect.
  var timeout = (new Date()) + (30 * 1000); // Don't let this run forever.
 
  var timeout_id = window.setTimeout(function() {
    console.debug("Font family of " + element.selector + ": " + element.css("font-family"));
    if ((new Date()) > timeout)
      window.clearTimeout(timeout_id);
  }, 1000); // Run every second.
)(); // Run it anonymously.

If Gecko works like we expect:

Use some JS w/ jQuery (similar to the above) like this:

(function() {
  if ($.browser.mozilla && ($.browser.version > 1.9.1)) {
    var element = $("#someid"); // Grab the element to inspect.
    var font    = "somefont"; // the font family you want
    var timeout = (new Date()) + (5 * 1000); // Give up after 5 seconds.
 
    // Set up your favorite hide-the-content-and-show-undefined-progress method here.
 
    var timeout_id = window.setTimeout(function() {
      if (
        ((new Date()) > timeout)
          ||
        (element.css("font-family") == font)
      ) {
 
        // Show the content here.
 
        window.clearTimeout(timeout_id);
      }
    }, 500); // setTimeout()
  } // if (gecko)
}(); // Run it anonymously.

Instead of adding an invalid element to the head or using JS to do the same thing, would the same technique work simply by applying a font-family rule to an existing element in the head?

title {font-family: 'ChunkFive Regular';}

hey Paul, good read. you really went in deep with this issue.
what about using the old staple of JavaScript preloading?? remember back in the day, preloading /choke/ rollover images?? since JS doesn't really know or care what it's downloading, theoretically can't you preload anything?? then it would be cached, I assume.

var preloadedFont = new Image();
preloadedFont.onload = function() {
    preloadedFont = null;
    // or delete preloadedFont; //... etc.
};
preloadedFont.src = 'font-file.ttf';

haven't tested it, but seems logical, no??

I realize that I am late to this party but this needs to be said, IMHO:

If you prefer the Safari way of displaying nothing until fonts are downloaded – fine! Thats your choice and your taste.

I think that getting to the content as quicky as posiible is better and wholeheartedly support Firefox's way of doing this. Although it can of course be improved. But until that happens, developers, please do not destroy my experience. Do not write scripts that will cause Firefox to mimick Safari. Respect your users!

I am appalled to see that people still thinks that everything should "look the same" in every browsers and consider doing UA sniffing to achieve desired effects. Are we back in 1998?

@Lars Gunther
amen!

i'm working on a site at dev.omsphoto.com, and put this code in the head.php file, and it shows up as text on the browser… is there something missing here? you can see it on the site now

@bob bingenheimer
The JavaScript should go inside <script> tags.

In text/html it's not possible to put "b" element in "head". Parser will close "head" and open "body" as soon as it sees "b", and then it may use error recovery to move some head-specific elements from body to head.

"No browsers download the font file when they find a css rule that references the @font-face font."

Something about that sounds wrong to me?

so your technique is to hide everything for whole 2 seconds because some text in the page doesn't look pretty for 2 seconds?
way to prioritize!

@bit – It's a matter of preference. In some instances one might prefer that delay instead of all of the page fonts shifting to their proper @font-face shortly after load. With some designs, that delay+shift looks awful, with others it's barely noticeable.

Either way, it's really nice to have the option (thanks to Paul) to decide ourselves whether we'll have delay+shift or not. At the moment, it's the best solution.

@Jeff Couturier

Personally, I think this is an amazing hack. Thanks for sharing, I'm definitely going to use it on sites where @font-face is crucial to the design and the flashing is very distracting.

I just plugged in typekit's webfontloader to get tight JS control of font loading. Seems to work at this point, so I hope to be spared any further low-level load-time debugging!

http://github.com/typekit/webfontloader

Thanks, as usual great info.

Big issue that is not mentioned, WebFont Loader does NOT support: iPhone, iPad, iPod, or Android. So the page renders only with the fallback font even though this devices are capable of rendering @font-face fonts (svg)

http://github.com/typekit/webfontloader/issues/#issue/14
http://code.google.com/apis/webfonts/faq.html#Browsers_Supported

Hi, here comes another "experience report": Although not mentioned in this excellent tutorial any more, we've finally turned back to including a span tag in the head for simlicity reasons. You can do a

....
 
          loadme
     ...

without losing XHTML 1.0 transitional valdiation (the browser puts it back to the body anyways because it's just a pointless abuse of the DTD structure). We've placed the @font-face declaration and this tag as early as possible into the head, especially before loading bigger javascript chunks (which is a blocking operation, that helps in this case!) and the effect is "statistically good enough" to avoid the FOUT without having to blind out the whole text or site until "onLoad" – the latter makes the site "blink" between pages.

Using external scripts like the fontloader JS seemed to make things rather worse in comparison to in-the-head javascript and css because they infer an extra delay and give the Browser the chance to apply "advanced optimizations" in the load sequence.

All the best, Nikolaus

PS: don't forget to test very good on XP machines without font smoothing (which is default there). not sufficiently hinted webfonts look horrible there.

dammit, code broken. tryagain:
<head>
…
<object>
<span style="font-family: myWebFont; visibility: hidden; position: absolute">loadme</span>
<object>
….
</head>

@Nikolaus Have you tried applying the font to an existing valid HEAD element, such as TITLE, instead of adding a dummy SPAN element?

Font Family does not affect page title which is only displayed on browser UI

Let me try that again:

<object>
            <span style=”font-family: myWebFont; visibility: hidden; position: absolute;”>loadme</span>
</object>

Looks like FF 3.6.11 has fixed the FOUT woot!

err well maybe is not completely fixed but it's almost un-noticeable.

For those of us who see text as something designed to be read, with aesthetic being secondary to that primary function, and who are using a browsers thankfully sane enough to display the text to the user as soon as possible, what measure would you suggest we take to prevent web developers fousting this technique upon their visitors?

I seem to have an issue where modernizr causes a second FOUT. You can see it (I hope) in Firefox here: http://firstlifeseries.com/media-coverage/ and the other pages on that site.

I've just now implemented the webfont.js method and it has removed the first FOUT, but there's still a second flash. If I remove the line that loads modernizr it goes away.

An easy solution might be to eliminate modernizr altogether (its only use on this site is for html5 tags). But it would be nice to find a genuine solution to the problem, so any thoughts or suggestions appreciated…

Great article and great script. I recently combined this with Zoltan Hawryluk’s font smooting detection script and use it on all my websites. (combined-script download and information, Website only in German, readme.txt inside the zip file in English) Works great!

Since Opera also has the FOUT problem (at least as far as I tested this), I added a second condition to address Opera 10.5 an above, too:

(e.style.MozTransform === '') || (e.style.OTransform === '')

Unfortunately I couldn’t find any suitable condition to address Opera 10.0.

Personally, I find this very helpful. I like the idea of loading the fonts before the page loads. It works really nicely and my clients love this solution. Cheers!

You don't have to call your CSS file in the api, you can set the following code as a default in your projects and then use google fonts freely.

JS

 
 
WebFont.load({
  custom: {
    families: ['Tangerine'] // Set your fonts
  }
});

In your normal css file:

/* Stop FOUT on Google Fonts */
.wf-loading {
  visibility: hidden;
}
.wf-active, .wf-inactive {
  visibility: visible;
}

And then you just add your custom font to any of your tags:
In your normal css file:

h2 {
    font-family: 'Tangerine', arial, serif;
}
#title {
    font-family: 'Tangerine', arial, serif;
}
etc...

The first code block got chopped =/

WebFont.load({
custom: {
families: ['Tangerine']
}
});

Has anybody here run into a FOUC that sticks?

In a new website I designed with two cool FontSquirrel fonts, Firefox 3.6 is intermittently ignoring my special font and resorting to the rollover for no apparent reason. Refreshing the page doesn't usually fix it, but navigating to a different page generally does. Totally bizarre! (and driving me crazy)

Fixed it. The problem seems to have to do with the old 'http://' vs 'http://www.' issue. A redirect pointing everything to the www version resolved the issue.

Thanks for the article,

Sorry if I will sound a bit dumb but just to summarize are you saying that writing a js script to hide all text for nn seconds is the best solution to date?

Thanks a lot, I also found gzipping very useful as mentioned by Stoyan. Will do optimization tomorrow

I'm not sure I like the idea of implementing custom script to override default behavior either; especially a potential three second artificial lag. On the other hand, I agree it would be nice to avoid the sometimes jarring effect of "FOUT".

Not tested, but a thought: How about including a low-res (re-sampled vectors, no hinting, etc.) subset (say, alphanumeric and common punctuation) of your high fidelity font as a data-uri,and then relying on the prioritization of the font-family declaration to show the low-res version before the hi-fi version is loaded?

@font-face { font-family: Fancyfont; src: url('Fancyfont-Roman.ttf'); }
@font-face { font-family: Fancyfont; font-weight: bold; src: url('Fancyfont-Bold.ttf'); }
 
@font-face { font-family: "Fancyfont min"; src: url("data:font/opentype;base64,[...]"); }
@font-face { font-family: "Fancyfont min"; font-weight: bold; src: url("data:font/opentype;base64,[...]"); }
 
h1 { font-family: Fancyfont, "Fancyfont min", Helvetica, sans-serif; }

The biggest drawback I see of course is the ballooning of download size.

If it were possible to include an svg in the data uri, that might even help with mobile environments that don't support ttf or otf.

I leave it to someone with more time than I have to take this thought further if they deem it to have merit. :)

Cheers,
David Twist

you know what helped me with FOUT?
- putting font-face related css in separate stylesheet and including it before everything

if your using Typekit they added font events to control there FOUT problems.

https://typekit.assistly.com/customer/portal/articles/6852-controlling-the-flash-of-unstyled-text-or-fout-using-font-events

Hi

I had the same problem with Cufon – a flash of the unstyled text as the font loaded. I tried the visibility hidden trick before the font was replaced but IE did not support this (of course – the fonts remained invisible when visibility was reset to 'visible'). The solution was to use a negative text-indent rule on the elements to be cufon'd. Not sure if the same solution could be used on font-face.

Some more info here:
http://www.codem.com.au/streams/2010/web-development/cufon-and-the-flash-of-unstyled-text.html

Cheers!

Paul,

Man – I read this post before updating my site w/ html5boilerplate and font-face (Google Font API) and I felt that having the FF approach was best – to get the content out as fast as possible.
Now, after updating my site I find that font upgrade FOUT to be so ugly that I love the fact that WebKit keeps it invisible until all is downloaded. Going to have to apply some of the techniques here to mitigate. Glad you wrote about this.

Cheers

I have found a simpler way to fix the FOUT problem – not sure if anyone will approve but I think it's a little more straight forward.

Use css FF conditional statement to turn off font visibility

h2,h3,h4,h5,#mainnav a, x:-moz-any-link {
     visibility:hidden;
}

Then use jquery to turn on visibility when the page has loaded

 jQuery(document).ready(function() {
   $('h2, h3, h4, h5, #mainnav a').css('visibility','visible');
 });

Your script works great on FF3xx. Thanks.
Have you had an opportunity to test whether it works on IE9?
(FF4=no fout, IE9=fout …all some sort of practical joke gone wrong…)

Thanks again for the good work, makes @font-face viable for me.

@Paul I see you point but in testing it seem to work well so… go figure!

Ahhhh ff4 / ie9 bah!!!

Way to go to override a behavior the user should be in control of!

> First, we are detecting if we're firefox 3.5+ by seeing if -moz-transform is supported, which was added at the same time.

And way to go to do wrong feature detection!

hey there, browsing your solutions, and other webs around, including WebFont Loader from Google, here's mine.

In my case it was not easy to include all the css styles so I made this workaround to avoid making any style.

Hope you find it useful. Thanks for your help!

 
WebFontConfig = {
custom: { families: [ 'MyFontFamily' ] },
	fontactive: function(fontFamily, fontDescription) {
//put here your divs to show when loaded and hide your "loading" sign
	   document.getElementById('wrapper').style.display=''; 
	   document.getElementById('loader').style.display='none'; 
		}};
      (function() {
        var wf = document.createElement('script');
        wf.src = ('https:' == document.location.protocol ? 'https' : 'http') +
            '://ajax.googleapis.com/ajax/libs/webfont/1/webfont.js';
        wf.type = 'text/javascript';
        wf.async = 'true';
        var s = document.getElementsByTagName('script')[0];
        s.parentNode.insertBefore(wf, s);
      })();

Loading...

(...)

(last part, the html)

Loading…

(…)

Here's how I got my fonts to load high up on the page and fixed the FOUT problem enough for us to deal with it:

1. Load the @font-face first
2. Put a span right after this in the head section
3. Code the span so it is displayed off the screen eg.(top:-1000px)

 
Load Font

CONTENTS OF @font-face.css:

/* hackish but loads the font first */
.load-font {
	top:-1000px;
	position:absolute;
	display:inline;
	visibility:hidden;
	font-family: 'VegurRegular';
}

@font-face {
    font-family: 'VegurRegular';
    src: url('vegur-r_0500-webfont.eot');
    src: url('vegur-r_0500-webfont.eot?iefix') format('eot'),
         url('vegur-r_0500-webfont.woff') format('woff'),
         url('vegur-r_0500-webfont.ttf') format('truetype'),
         url('vegur-r_0500-webfont.svg#webfontLyK1FZ0K') format('svg');
    font-weight: normal;
    font-style: normal;

}

Missing code from last post:

 
 
Load Font

Hey Paul,

We have written a FOUT script that expands on your initial work and would like to share it with the community. FOUT-B-Gone – as we call it – will control FOUT for @font-face calls. Right now we cover IE7-9 and FF3.5/3.6 but we should have an Opera modification to the script soon. And as we all know there is no reason to cover FF4 as it has FOUT control built in it.

http://www.extensis.com/en/WebINK/fout-b-gone/

This will work for local @font-face calls inside your own CSS files. We don't recommend this for use with services that host your CSS on their domain as you will see script errors in Firefox do to cross domain security issues. We are looking into a version that is not as robust but handles this issue, basically removing the CSS inspection that we do to figure out what @font-face calls are coming down on the page.

If anyone has comments or issues please let us know at webink@extensis.com

Brad

@Adam FLorin

I use WebFontLoader and do the essentially the following:

.wf { }
.webfont-a { font-family: "webfonta", arial, verdana, sans-serif; }
.webfont-b { font-family: "webfontb", georgia, times, serif; }

.wf-loading .wf { visibility: hidden; }
.wf-active .wf { visibility: visible; }

Hello!
Hey!

Found that eliminates any issues with FOUT. Tested with CharlesProxy on slower connections and there is a noticable delay in the appearance of content but its no different than waiting for images, side-bars, etc to come down, etc.

@Paul Michael Smith

Doh, Hello! & Hey! should have been

[code]
Hello!
Hey!
[/code]

Thanks for the update!

Regarding the remark that IE9 "requires an embedding bit set thing", in the 2011.04.14 update, this appears to be a non-issue. IE9 requires this only from raw TTF/OTF fonts but not WOFF or EOT fonts. And since IE9 accepts the latter formats too, it can be served webfonts without any format fulfilling this requirement. I tried a summary and, following your link, realize now that you effectively said so when you suggested to "solve this by [...] serving a WOFF". With the exception of Safari, WOFF is now supported by all major browsers.

Great write-up!
I think I agree with Remy Sharp though. I think that a short flash would bother me less on a fast connection, than a never-ending wait would on a slow connection…

Also, in these days of WPO (and Google stating 100ms as a goal), delaying all text (or even worse, the whole page) for up to 3 seconds seems like a step in the wrong direction.

I really can't understand what's all about that FOUT. I don't bother if the @font-face fonts display now or then or 2 seconds sooner or later as long as the text IS there. I think it's pretty trivial if there is another font for a short period of time or if it looks ugly. I think this FOUT thing is a little bit blown out of proportion …

WebInk's solution doesn't work with :first-letter

.dropcap:first-letter {
    font-style: none;
    float: left;
    font-family: eurofurence light, arial;
    font-size: 250%;
    line-height: 0.5em;
    margin: 18px 13px 0 0;
}

I see some other problem with Firefox4 – it is NOT caching the fonts in TTF or WOFF format. I tested this on Open Suse 11.4 and Windows with FF 4.01.

The webserver (NGINX) is sending the correct MIME types and also an expiry headers:

Server nginx/0.7.65
Date Mon, 02 May 2011 10:35:33 GMT
Content-Type application/x-font-ttf
Content-Length 30844
Last-Modified Tue, 05 Apr 2011 15:09:54 GMT
Connection keep-alive
Expires Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control max-age=315360000
Accept-Ranges bytes

All other browsers (including legacy FF3.6) are caching the files. FF4 doesn't cache them => there is a 1-2 second delay in displaying texts with the custom font on EACH page.

Even IE9 is getting this right!

I am disappointed to see that after the discussions about fonts, FF4 is fucking up this part.

I also added expires to .htaccess. With google font api described in this doc, everything seems to be working nicely. I think the .wf-loading isn't even triggered (it's so great!).

AddType application/vnd.bw-fontobject .eot
AddType application/x-font-ttf .ttf
AddType application/x-woff .woff

ExpiresActive On
ExpiresByType application/vnd.bw-fontobject "access plus 1 year"
ExpiresByType application/x-font-ttf "access plus 1 year"
ExpiresByType application/x-woff "access plus 1 year"

I'm using fout-b-gone but it makes appear my text 7 secondes after loading, while the font is ready after some miliseconds.
Does someone know why?

Thank you Paul, and everyone who's added to this article. Simply fantastic.

Hey man

Your website is killing my browser in linux

You spend so much time with this stupid draw thing in the background that it uses 2+ gigs of ram (in firefox)

Weak programming man

@Shitty site
FYI, Win7 + IE9 on this site is using about 10 meg of memory.

Maybe you should upgrade your OS and browser ;)

It’s really a great and helpful piece of info. I’m glad that you shared this useful information with us. Please keep us informed like this. Thank you for sharing.

Anyone else seeing an error in IE8 with FOUT-B-Gone? I'm getting an "HTML Parsing Error: Unable to modify the parent container element before the child element is closed (KB927917)

?

Strange, I moved it just under the body tag (and out of the header) and the pages now load in IE8 with no parsing errors.

Paul already mentioned it on the last update, but let's recap a little: it seems "some delayed FOUT" is going to be the norm across browsers.

"Normal" (i.e. just using @font-face) font loading is widely supported, and it seems major browsers are aiming to this sequence:

(1) render blank for some seconds (0.5s < t < 3s)
(2) render text with fallback fonts until download finishes
(3) render text using webfonts

IMO, the Webfont Loader may not provide any benefit over this sequence, and will just add unnecessary overhead (extra JS download/execution and extra CSS maintenance).

I've briefly tested (but will appreciate someone else testing and confirming) that both Firefox 5/7 and Chromium 13/14 already present the behavior of falling back to locally available (system) fonts.

As a proof of this, Firefox includes the setting "gfx.downloadable_fonts.fallback_delay" (set to 3000ms by default). In the case of Chromium, I couldn't find any clue that this mechanism was already implemented, but I've done some tests by delaying the loading of the webfont, and it seemed to follow the above sequence.

So, bottom line: in the current state of affairs, I see no reason to continue using the Webfont Loader solution, even if IE9 is reported to just do steps 2 and 3 of the above sequence (i.e. no blank rendering at the very beginning of page load).

I like the acronym FOUT (flash of unstyled font). I think you have taken it from FOUC which stands for Flash Of Unstyled Content. FOUC occurs when you add your CSS at the bottom of your page.

@Lars Gunther I'm late to this too, but agree here.

Whether you are a web developer or a designer, you are [supposed to be] taught that the primary goal of your job is communication. Hiding information is not communicating. It's self-serving and we aren't supposed to be in the business of making ourselves happy, we're supposed to be doing our jobs for the end-user.

The problem that is being dealt with is the delay caused by load time of a file that takes time to load. And this solution is add code to the HTML document – which increases file size. That's working across purposes. Although in this age, for most users the added code is still virtually a non-factor, it still takes away load time for the font. Additionally, anyone so consumed with site appearance to need this method probably loads the site with graphics, so the site itself is already slow-loading. Adding more code doesn't help.

I know this comment is well after the article went up, but I just read it today – and probably others are just seeing it for the first time, as well.

While I don't agree with the technique described in the javascript unless it only affects the web text, I don't think that we're talking only about self-serving principles when we're dealing with manipulating the default behaviors of font-face here. Personally, the reason font-face seems so essential to me is readability. Having font variety can add to readability and emphasis(can). And if the (subtle) purpose of using font-face is indeed readable emphasis, then having a jarring FOUT will far overshadow that benefit.

Anyway, the solution I intend to follow, in the vein of the approach above, is adding an animated effect in time with loading problems. Essentially instead of providing nothing via js, performing a slight fadein so that users know to expect something. I'll see how that works out.