Ok, that´s great, thanks.

Sura Mandy, email sent, hope it helps.

Rafal, could you share your URL with support@typekit.com? We can take a look. Using the .wf-loading classes should not affect Safari’s behavior.

Couldn’t this target problem browsers (i.e. Firefox) only?

Jason said it: “It’s up to you to use the font events as you want”. If you prefer the Firefox-style “first render in fallbacks, then in webfonts” behavior for loading your site, you can achieve that effect in all browsers using font events as well. Just apply the Typekit font-family names only on .wf-active. For example:

.blog-title {
font-family: Arial, sans-serif;
}

.wf-active .blog-title {
font-family: “museo-sans-1”, “museo-sans-2”, Arial, sans-serif;
}

The point is that font events give you control over how web fonts load in all browsers. You can do nothing and go with the each browser’s default behavior or use font events to achieve a particular behavior in all browsers. I wrote from the perspective of matching the WebKit behavior since many web developers seem to prefer that (as long as the fonts load quickly). Typekit’s JavaScript has a timeout that ensures that people won’t see hidden text for too long.

Speaking as a Typekit user, I think calling it “a while” may be misleading. This is a very brief < 1 second flash. In that context, going from no text to styled text might be less distracting because users' eyes might not even notice the brief millisecond of load time. Alternatively, loading the fallback font and then switching over to the Typekit font draws a lot more attention to that millisecond.

Ultimately, it's up to you to use the font events as you want.

It’s one more tool in the web developer’s toolbox, but it’s up to you to design what you want the loading experience of your page to be. Some developers prefer to show content as soon as possible, even if the resources to style the content correctly aren’t yet available. Others would rather wait a short time to show the content once it can be styled correctly.