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