Deal with FOUT (Flash Of Unstyled Text)

An issue has been created with regards to Typekit.
http://drupal.org/node/1202474

As far as I can tell, the only sane way to do this right now would be via a javascript loader that changes states so you can control what happens with the font - I was thinking of doing the same way back until I saw the webfont loader project and its why my module was based on it (which isn't perfect but has support for a lot of stuff). I think you could do it via flash as well though that has a number of issues. My 2 cents so far though.

Wow, I wasn't expecting this at all. I'm definitely in favor of this :) (1) seems quite doable though (2) will require some more looking into (I do see you have a link and that may be all that needs to be followed?) to see what performance is like. I have typically made all the rulings in my css file(s) so this would change things a fair bit.

As long as you can tap into the WebFont Loader so it injects the classes (.wf-inactive .wf-loaded, etc) then the theme can handle dealing with it. You can add CSS that doesn't include the web fonts (i.e. only the fallback fonts) and style them differently with size, line-height and letter-spacing. Works great. Hopefully the article I wrote up on it with example bits will be live on the Fonts.com blog soon - I'll post a link when it is.

Jason

subscribe - the FOUT is pretty painful on a site I am developing right now. Module works great - if you can figure out a way to work around the FOUT, it will be perfect!

I wanted to update things on my end regarding the webfont loader module. I have tacked (2) in #4 and put it in the latest releases of the module. I am not entirely sure on how to describe it (other than default behavior and 'hidden' behavior with a long description to go with it). But the loading is working as intended. Will have to tackle (1) at some point so it satisfies ways to integrate with your work.

I've created the issue at #1285750: Make font loading more flexible (since most of it deals with my module) if you had any suggestions on approaches to make it more flexible.

Just a followup - now that the web font events are starting to be used, I've written up a way to deal with FOUT pretty effectively here: http://bit.ly/pF5qlr (on Fonts.com's blog) Hope it's helpful!

Jason

@jpamental What I have is very close to what you have in your post (though I'm not using the <noscript> tags.

Awesome, I'll test and check out how you added the code :)

I had a chance to test it out and what I see happening right now is that the font gets loaded twice (once via the fontyourface_add_css_in_preprocess($vars, $url, 'remote'); and again by the webfontloader (which calls on the font from google). Not entirely sure on how much of an issue it is since the response would likely get cached on the user's end. But adding it into an else statement would clear it up (if using webfontloader, load the font via its function, otherwise use fontyourface preprocessing).

As an example (I don't know if you want to head in this route), the way I had handled this was with the attached diff.

Jumped in here with @BTMash on IRC this evening.

Went through the Typekit provider for google_webfont_loader_api and saw that the integration is unnecessary as the Typekit js mimics the same methods as the loader. I will try another provider in the next few days and see where I get to helping implement some of the first task that @BTMash is talking about in #4

Alright, I have been able to get fontsquirrel and local imported fonts working. I updated my module's codebase to be a little more flexible (so it can accept various kinds of streams) and it is working against those changes. Attaching patch for review.

Hi all!

I updated to the dev code and for me the FOUT is still there when using Typekit Font.

I am not 100% sure, but it looks like I have to add some CSS to hide the fonts while the html tag has its
wf-loading-class set.

This now works for me. I just used to hide the whole html with it, because I load a lot of text with downloaded fonts.

.wf-loading {
  visibility: hidden;
}

I am not sure if this is the correct way, but I didn't found any setting or similar on the dev code.
Is this correct and documented somewhere ? Or should we add these info for other people if it is correct?
I fought a long time to bring these FOUT away...

Regards Cyclodex

Hmm, that would be the correct way. I had not modified the code for the typekit provider since that was already using a variant of the webfont loader module's js (as mentioned by @stevenator in http://drupal.org/node/1187682#comment-5546392). I could certainly create a patch for this though we should then do it for all the possible providers then regardless of them using their own js. Providers that I see that could still use it (and that I have it working for in my module) would be:

• fontdeck
• font.com
• typekit

That *should* cover all the provider modules then. Any thoughts, @sreynen?

Ah okay.

I am not sure if we/you should let the users add themselves CSS stuff regarding what to hide:

• then I would suggest to make a info somewhere so that people knows what they would have to do for not having a FOUT on FireFox.
• Or if you want to add a additional option to let the people add the CSS in the module configuration, for example next to the fonts with a checkbox? Just Ideas ...

Could be an option. Thanks for the quick reply !

Ah so that's why I had to implement my own css styles to handle it...

I can try to split apart the css loading portion some more so it does a check (has the hidden css been requested? yes, add it in regardless.). The way I'm thinking right now is it can be its own function in case things change in the future (tentatively called _google_webfont_loader_api_add_hidden_css()). The css being added is fairly safe (hopefully a class of 'wf-loading' does not get added in by another module/theme that happens to use the webfont loader module). And it has taken me all of 5 minutes to write it in.

With that said...do you really want to load an additional module that is just going to add 6 lines of css? :( Though I agree that webfont loader js is heavier in the sense that other checks are going on which would likely make the processing of the js slower than from typekit.

Alright, alright, you've strong-armed me with your argument :P I've committed the patch so it should now handle that since typekit comes with its own font-loader variant. So I am now left with figuring out how to handle fontdeck and fonts.com. From what I see fontdeck also seems to use the Webfont Loader library so we just need to see if they already handle FOUT (if not, my commit should take care of it and you don't have to change anything). Alternately, since it is wholly using webfont.js, it could be switched over to what I have and there should be little to no impact in performance.

font.com (ascender) will need to switch over into using the WFL module library instead of the js it provides since I don't see it adding any other code into the page that I could directly work with via css (unless it takes care of itself).

I had a chance to look through what font.com does in the js and it seems like they do handle it themselves so it may not need to be managed. Unless we still want to.

I made a bunch of code changes so it should all be working as expected (with dev - I'm planning to make a stable release of WFL on Monday) so it *should* be resolved. Marking as needs review.

I've been tinkering with @font-your-face for several month now (both 7.x and 6.x), and haven't seen a glimpse of FOUT, so this seems fixed. :)

If someone knows the steps to produce some FOUT, feel free to reopen.

(On a side note, I recently stumbled on some script to deal with FOUT - http://www.webink.com/fout-b-gone/ - although at the moment we don't seem to need it, I'm posting a link just in case we still need to work on this later)