Flash of Unstyled Content (FOUC)
Flash of Unstyled Content (FOUC)
What is a FOUC?
Some pages that use the CSS @import rule experience a curious display quirk in the Windows version of MS Internet Explorer: a momentary flash of unstyled page content. The unimaginative creature that I am, I call this phenomenon Flash of Unstyled Content or FOUC for short.
Because this quirk seems to affect only MS Internet Explorer, we're tempted to conclude that IE is just plain wrong. I am not going to jump to that conclusion. It is unclear to me whether or not a FOUC afflicted user agent is in disagreement with any W3C recommendation. Though I can't speak for the W3C, I can say that I would prefer that Internet Explorer ditch the flash of unstyled content.
How do I see a FOUC?
First, you will need to be using IE for Windows (version 5 or above). Then, you'll need to find a page that exhibits the FOUC phenomenon. You won't need to search long - this very page¹ is a great example.
Now, this is very important. If the imported stylesheet is in IE's cache (also called Temporary Internet Files), the flash of unstyled content will not rear its ugly head. For testing purposes, delete IE's Temporary Internet Files before viewing the FOUC-inducing page. If you're not sure how to do this, please refer to Microsoft's brief online instructions. Below is my suggested method to test for a FOUC.
- Load the page that you want to test into an IE5+/Win browser window. This very page¹ is an excellent page to test.
- Load a different page into the browser window. The page that you chose for this step is not important, as long as it does not share files with the page that you are testing. A page from a different site is a good choice here (for example, the Google home page).
- Delete your Temporary Internet Files. If needed, instructions are available.
- Press the "Back" button to return to the page that you wish to test.
- Watch for the flash of unstyled content.
Please note that some factors, like a slow PC or proximity to network equipment with caching capabilities, may reduce the chance that you'll witness the flash of unstyled content display quirk. For example, I have a 100MHz Pentium PC running IE5/Win that will not exhibit this phenomenon for even the worst FOUC-afflicted pages.
What's the backstory?
When I first converted bluerobot.com to a CSS-based layout (18 FEB 2001), the design suffered from the FOUC phenomenon. It was immediately clear that this odd display quirk was somehow connected to the use of the CSS2 @import rule. Because the @import rule is widely used to hide complex CSS rules from CSS-impaired browsers (e.g. Netscape Navigator 4.x), the FOUC phenomenon has the potential to be more than just a small annoyance.
That said, I must admit that I've only recently given the FOUC issue more than a passing thought. The split-second rendering of raw content seemed somehow fitting on the BlueRobot home page. However, I've received too many emails regarding this issue to pretend that it's not a concern.
Is it all in my HEAD?
So, why do some pages (e.g. this page¹) exhibit the FOUC, while others (e.g. A List Apart) do not? Well, the ALA home page sure has more stuff inside its HEAD element than does this page. Of particular interest, the HEAD element on the ALA home page contains a couple of SCRIPT elements and a handful of LINK elements, while this page¹ contains no such elements. There's a solution in there somewhere.
How do I vanquish the FOUC? (How do I fix it?)
Just one LINK element or SCRIPT element inside a document's HEAD element will prevent a flash of unstyled content.
The basic HEAD element
For the purposes of comparison, below is the basic HEAD element that is susceptible to the FOUC phenomenon.
Test the basic HEAD element for the FOUC phenomenon.
<head>
<title>My Page</title>
<style type="text/css" media="screen">@import "style.css";</style>
</head>
The LINK element solution
The addition of a LINK element to the basic HEAD element is probably the most natural solution to the FOUC problem. This is because almost every page can benefit from the addition of either an alternate stylesheet or a media-dependent stylesheet. I recommend this solution, because it both prevents the FOUC display quirk and improves the page in some other way: either usability, accessibility, or some other fancy buzzword. Of course, this solution works even if the added LINK element refers to an empty stylesheet. But what a waste that would be.
Test the LINK element solution for the FOUC phenomenon.
<head>
<title>My Page</title>
<link rel="stylesheet" type="text/css" media="print" href="print.css">
<style type="text/css" media="screen">@import "style.css";</style>
</head>
The SCRIPT element solution
The addition of a SCRIPT element to the basic HEAD element is an effective solution to the FOUC problem. However, it may seem somewhat unnatural to add a SCRIPT element to some pages. For example, I believe there is no script that would improve this page. I could add an empty SCRIPT element to the HEAD of this page, but that feels an awful lot like a hack. In cases like this, opt for the LINK element solution.
I should mention here that the SCRIPT element does not need to be inside the HEAD element to thwart the FOUC phenomenon. It does need to appear in the markup before all content contained by the BODY element. Therefore, placing a SCRIPT element inside the BODY element, but before all visual content, is also an effective way to prevent a FOUC.
Test the SCRIPT element solution for the FOUC phenomenon.
<head>
<title>My Page</title>
<script type="text/javascript"> </script>
<style type="text/css" media="screen">@import "style.css";</style>
</head>
How can I help?
If you know of any resources on the FOUC phenomenon, or have any related information for me, please let me know. There must be more information out there. I'd like to continue to improve our understanding of this pesky display quirk. And for heaven's sake, please let me know if you encounter any problems or errant information on this page. I appreciate any and all help.
Acknowledgements
I'd like to give a special thanks to Shawn Wall for sharing ideas, testing pages, and generally motivating me to get off my butt and write this document.
