Firefox forces orange background flash

There’s good news and bad news. The good news is that Firefox 3.0 and 3.5 for Windows no longer cut long pages of this site in half, hiding 50% or more of the pages’ content, including the footer, because of a newly discovered bug in Firefox (discovered by this site’s layout).

The bad news is that the price of the “fix” is an annoying flash of reddish-orange background. When you first load a page in any browser, rather than the main content’s off-white background area, you instead see the text against a reddish-orange background, obscuring words (including the drop cap), disrupting user experience, and raising doubts about the professionalism of the site and thus of the opinions it expresses.

With the annoying flash of colored background, everyone who reads this site suffers. But without it, Firefox 3/3.5 cuts long pages in half. Until Firefox fixes the bug, all readers of this site will experience what I’ll label “the Flash of wrongly styled background color.” (Note: although the browser is still broken, the color flash has since been “fixed.” Impatient ones, skip ahead to the 9 July update. Narrative fans, keep reading.)

Here’s the story.

Validators were no help

My 2 July post, XHTML DOA WTF, has thus far received 194 comments. Firefox users told me the thread “died” after comment #44049 in Firefox 3 and 3.5 for Windows. The problem also later surfaced on In Defense of Web Developers, written yesterday morning just prior to my surgery. Let’s stick with the 2 July post, though, which is where we did our Q&A.

W3C and WDG validation services both indicated that there was an error on the page, but neither validator could explain it.

  • The W3C showed a long list of unclosed elements (which in fact were closed), a typical W3C validation error when that validator misidentifies the actual problem. The W3C validator has made this mistake since at least 2001. Whenever I complain to the W3C, I’m told they need volunteers to help them fix the validator. So I more often rely on the WDG validation service.
  • The WDG validator (usefully and apparently correctly) indicated that a single illegal UTF character in a comment it could not show me was causing the dilemma. This validator gave me a line number, but no code output—making the line number useless, and forcing me to go into my database and examine each of 194 comments visually for unsupported character problems.

In search of a single UTF-16 character

I next spent two hours of an insanely busy pre-surgery day unsuccessfully attempting to manually track down UTF errors in comments that no validation service was able to pointpoint. I had to apologize to colleagues and clients to whom I owed work, since the quest to make my personal site legible and usable to Firefox users took precedence over paying work in my sad little mind. (Call it a mark of the high esteem in which I hold Firefox; also call it a concern for readers.)

Automattic’s designer/developer (and my friend) Noel Jackson then took over for me and was eventually able to locate a single UTF error in a Japanese pingback. Or so it seemed.

WordPress, the power behind this site, is supposed to convert illegal UTF-16 to legal UTF-8, and we thought it had done so. Nevertheless, the only validation service to have claimed anything semi-coherent said otherwise. To solve the problem required brute force: we deleted the entire Japanese comment. To the clients and colleagues to whom I owed work I was unable to finish while tracking down a Firefox bug, I now also owed an apology to a Japanese blogger. Personally, I blamed Firefox for ludicrously Draconian error handling, but at least I thought we had “solved” the needless problem raised by such behavior.

Drudge work for nothing

I owe Firefox an apology. Draconian error handling of impossible-to-trace possible UTF errors was not the cause of its failure to display pages correctly. Inability to parse valid CSS on long pages was the actual cause.

Although my page now validated, Firefox still cut it off at the waist. Thanks to this bug, users of Firefox—many of whom care greatly about web standards (it’s one reason so many developers choose Firefox)—were unable to read more than half the comments about XHTML 2 and HTML 5 from their fellow standardistas. They were also unable to post comments or view the footer (thus making them unable to view other content on this site, as well as third-party site highlighted in the footer). This was a win for nobody, except maybe Microsoft, Opera, and Safari. And, like I said, we like Firefox and people who use it. Back to the drawing board.

Seek and ye shall not find

Nikolay Bachiyski, a lead developer at Automattic, then conducted a series of tests:

  1. He established that only Firefox 3.0/3.5 (and only in Windows) cut the valid web page’s content in half.
  2. He verified that the page’s content was valid (UTF-8) as was its markup.
  3. The DOM loaded properly.
  4. There wasn’t an (X)HTML parsing problem.
  5. Disabling JavaScript made no difference.
  6. Disabling CSS enabled all the page’s content to display in Firefox; turning CSS back on cut the page in half again. Clearly, the issue was with CSS.
  7. Nikolay then disabled the lines of Mozilla- and Webkit- oriented CSS3 that generate “warnings” or “errors” in the W3C validation service. But even with those lines disabled and the CSS completely valid, the page’s content failed to display completely in Firefox. The bottom of the page was still cut off.

A CSS “fix” with a drawback

Valid CSS was somehow to “blame” for Firefox’s inability to show a long page without hiding half the content.

You may ask why I didn’t discover this problem during the building and testing of my site’s redesign. You might even ask why my readers didn’t discover it (since I beta tested the redesign at several stages). The answer is simple. I never tested a dummy blog post with nearly 200 comments. It didn’t occur to me that more than 40 comments would be necessary to test whether valid CSS and XHTML would work in good modern browsers, let alone in one as excellent as Firefox.

Michel Bozgounov and Kyle Weems then proposed a simple CSS fix:

div#wrapper {overflow: visible;}

My friend Noel implemented the CSS fix while I was unconscious and having stuff cut out of me.

It works, and I thank all these gentlemen. But it has the unfortunately side-effect of inflicting a flash of reddish-orange background on the page until most or all content has loaded. (I had previously spent over two weeks eliminating that flash of background.) And it does this in all browsers (or nearly all), not just Firefox. To force Firefox to display all content on a page, I have to force every other browser to flash red before it shows content.

Obviously, it’s vital that Firefox users be enabled to read and comment on long or popular posts. But there must be a better way than deforming the CSS. And there is a better way: namely, a Firefox bug fix.

Our friends at WordPress have contacted our friends at Mozilla, so we are hopeful that this will be fast-tracked. Mozilla friends, call on me to help at any time.

9 July Update: 99% solution

With the addition of 1000px of min-height to #wrapper, the reddish-orange flash has been eliminated, at least in pages that load quickly. (On long pages, or with slow connections, the reddish-orange background remains painfully visible until the page finishes loading.) Read more about this CSS adjustment. Note that adding CSS workarounds is not the same thing as fixing browser bugs. (Indeed, CSS workarounds may retard browser development by removing the problem so it never gets fixed.)

A Firefox Test Page

As I am not entirely satisfied with this CSS workaround (despite my gratitude to its authors) and as I do not want Mozilla’s engineering wizards to be unable to fix Firefox because of changes to my CSS, I have posted a Firefox test page using the site’s original (perfectly fine, background-flash-less) CSS, and a page explaining the Firefox test page.—JZ

Read more

  • HTML 5: Nav Ambiguity Resolved. An e-mail from Chairman Hickson resolves an ambiguity in the nav element of HTML 5. What does that mean in English? Glad you asked! — 13 July 2009
  • Web Standards Secret Sauce: Even though Firefox and Opera offered powerfully compelling visions of what could be accomplished with web standards back when IE6 offered a poor experience, Firefox and Opera, not unlike Linux and Mac OS, were platforms for the converted. Thanks largely to the success of the iPhone, Webkit, in the form of Safari, has been a surprising force for good on the web, raising people’s expectations about what a web browser can and should do, and what a web page should look like. — 12 July 2009
  • In Defense of Web Developers: Pushing back against the “XHTML is bullshit, man!” crowd’s using the cessation of XHTML 2.0 activity to condescend to—or even childishly glory in the “folly” of—web developers who build with XHTML 1.0, a stable W3C recommendation for nearly ten years, and one that will continue to work indefinitely. — 7 July 2009
  • XHTML DOA WTF: The web’s future isn’t what the web’s past cracked it up to be. — 2 July 2009

[tags]browser, bugs, Firefox3, Firefox3.5, Firefox/Windows, browsers, firefoxbugs[/tags]

68 thoughts on “Firefox forces orange background flash

  1. Seems to have this same flash of red on “Safari Touch”

    PRECISELY. That’s the point. It now has the same flash of red in ALL BROWSERS. In order to fix display in Safari, I had to mess up display in all browsers. Sorry if that wasn’t clear from the post.

    And now I really must rest. I’m bandaged like the mummy and it hurts when I cough. Off to the nearest couch I go. But please carry on, you lovers of design, web standards, browsers, code, and minutia.

  2. I haven’t tested it yet, and am unsure if it’ll work with how your site is laid out, but if you move the background image of your main content onto the body tag, centered appropriately, etc, it might prevent the flash, as it’s clear that the body’s background is loading earlier.

    I’ll have to test a duplicate of the page to see if that works.

  3. but if you move the background image of your main content onto the body tag, centered appropriately, etc, it might prevent the flash, as it’s clear that the body’s background is loading earlier.

    If I recall, that’s where the off-white background was in my original CSS, and I discontinued it because of a rounding problem with the centering (which caused an extra pixel of right border to appear on the right side of the content area).

    But you may be cleverer at this than I am. Go for it.

    With my thanks.

    And now I seriously have to lie down before my health suffers. Laters.

  4. Add a background image matching the site content area repeating on the y axis on body. Make it 2px less wide than #wrapper is to avoid a 1px gap on the offset pixel. Problem solved. Hacky, but should do the trick.

  5. One could always use your handy style-switcher in the footer to change the page background to off-white until the issue is resolved.

    It kills some of the unique, and wonderful, branding of the site, but a least the “the Flash of wrongly styled background color” is from off-white to slightly-different-off-white instead of the jarring red.

  6. Good lord, Jeffrey, you work too hard! I was going to pretend-shout at you to get some rest before seeing your comment above – hopefully you actually are putting your feet up and not sneakily following the comments posted here ;)

    Seriously, take it really easy for the next few days, otherwise your recovery will take that bit longer. We know how dedicated you are, but the world won’t end if your site flashes momentarily for a few days while you get better and we won’t think the worse of you for it.

  7. Weren’t there a couple of suggested solutions to the red flash problem originally? Any of those help now? It’ll be very interesting to see what the actual bug turns out to be in the end, when it’s been reduced (as much as you can reduce a bug related to content length!).

    PS. I think you say Safari when you mean Firefox about 3 paragraphs from the end.

  8. I told you about this 3 weeks ago in a personal message via your contact form; there was no response from you so I thought I was crazy and half-screen-blind. Anyway!

  9. In the third to last paragraph it says:

    And it does this in all browsers, not just Safari. To force Safari to display all content on a page, I have to force every other browser to flash red before it shows content.

    Shouldn’t that say “Firefox” instead of “Safari”?

  10. If it’s any use, putting the background on the <body> element doesn’t help Safari in the least. What does help is a very ugly repeating of your backgrounds further down – on #maincontent and #sidebar. The sidebar takes a brief moment to fill down the whole page, but the rest looks fine. So for example:

    div#maincontent, div#sidebar {
    background-image: url(;
    background-repeat: repeat-y;
    background-color: #F9F8F3;
    div#maincontent {
    background-position: top left;
    div#sidebar {
    background-position: top right;

    Not tested in anything but Safari, but maybe it’s a starting point.

  11. May I try again to add my $ 0.02? :-)

    I think I have another simple solution which will fix pretty well the fix which you have applied to Firefox which should have fixed the problem with ‘Long pages cut in half’ (wow, that was a very ‘fix’-style phrase, LOL:-).

    Here’s the new ‘demo‘.

    I’ve quickly tested in Firefox 3, Safari 4, IE7 and Chrome 2, and things in the demo page look quite OK.

    (@hawkman: In Safari 4/Win, at least, the flash is almost not present, after I have applied the fix. In Firefox things look even better.)

    Basically, what I did:

    1) I created (again) an almost exact static copy of one of the problematically long pages from (only removing all JS from it); I also copied the original main CSS file that the design currently uses.

    2) In the CSS file, locally, I have changed only one line, and now the body has the following rule applied to it:
    background: #c30 url(ff-flash-fix.gif) top center repeat-y;
    (before it was: background: #c30;).

    3) Next, in Adobe Fireworks, I’ve created a small graphic with the color #F9F8F3, and exported it as a small GIF file, 769×5 px, and only 117 bytes big.

    4) Why 769 and not 770 pixels wide? I have my reasons. Earlier in your post, you mentioned that while working on your design, you abandoned the idea of applying an image to the body, because of browsers’ rounding errors, when trying to center an image. I know about this problem. But my goal was different. You have a ‘faux columns’ image already, and the design will continue to use it. But while the HTML/CSS/JS/images are loading, the browser, instead of showing first the red background (while the ‘faux columns’ image and the content are loading next, causing the quick flash), it will show the red background with the new body background image centered! And as the image is *very* small in size and its position is defined at the very beginning of the CSS file, this will prevent the flash almost 100%! So, things happen like this:

    a) you request the page,
    b) the browser starts loading the html/css/js/images,
    c) one of the first rules in the CSS file that the browser encounters is to make the color of the background #C30 and to position & repeat-y in the center a very small image, which it does, and
    d) as the image is very small, the flash is (almost) prevented and instead of red, the central part of the design becomes (thanks to the image) #F9F8F3, meanwhile
    e) the browser continues to load the content of the page, and once everything has loaded, the ‘faux columns’ appear on top of the underlying ‘fix’ background image, but almost un-noticeably, because they blend well.

    Because the image is destined to temporarily ‘paint the space’ for the faux-columns image (which usually will load a fraction of the second later), it can be 1 pixel narrower (this is because of rounding errors when centering), but this won’t be noticed at all; at the same time, this will prevent the flash in a very effective manner!

    So, what you need to do (if you decide to try this workaround):

    1) upload a copy of the fix image to:
    2) in the style.css, change the background of the body to:
    background: #c30 url(./i/ff-flash-fix.gif) top center repeat-y;
    3) test, test, test again! :-)

    This should fix the flashing for all browsers.

    Meanwhile, I hope that the Firefox gurus at Mozilla will be able to identify the bug which cuts longs pages in two, fix it, and then, later, you could remove both fixes from your code! :-)

    Finally, let me add that even before you decide to make any changes, you and your helpful readers may want to try, if the demo page that I have created, indeed works and 'flash' is not present in it (or is much less noticeable than now, here). That would help you decide if you really need/want to apply my fix.)

    ...There can be many more solutions, of course (including temporary server-side or client-side detection of Firefox and serving a separate small CSS file just for it), but maybe this one is one of the simpler ones... :)

    * * *

    Now I wish you speedy recovery and some time away from the computer and iPhone. You really need this, if you want to be well again, and sooner! Please, leave aside all worries about flashes & bugs & bugfixes... at least for some time!

    They can wait! :)

  12. @Michel: Works alright after the image is cached, but the first load is just as slow and flashy for me (Safari). Really, I’d have thought a solution that specifies a suitable background-color somewhere is desirable, ‘cos it’s the only way to eliminate the flash entirely; otherwise it persists as long as you wait for an image. (The result, though, is that if you’re specifying the color it hides the image behind it – hence the need to repeat the image on these elements.)

    Still, your approach does reduce the length of the flash on subsequent page loads. Either approach is fine in Firefox, which interestingly seems to be waiting longer before showing me the page.

  13. Gee. I’m going in the hospital tomorrow for a routine test, too.

    Jeffrey, it almost sounds like you found a bug but now you’re jumping up and down shouting about those insane Firefox people. “How could they let such a bug through and why didn’t they discover it before I did?!!!”

    You’re not the first, ya’ know. Maybe that’s not your intention but it sure comes across like it is. If it was your intention, I’m surprised.

  14. @Michel:

    Short answer: your solution is ingenious and echoes what another reader on this page suggested. Most importantly, your demo page works in Safari (no flash). Thanks for the hard work!

    It would be great if other readers tested and reported.

    Obviously I’d rather have Firefox fix the bug than me implement yet another CSS hack involving a background image.

    That said, it’s a pretty harmless hack, and I wouldn’t have objected to using a GIF background to create a drop-shadow or gradient, so I shouldn’t object to using a flat color GIF to replace a CSS flat color.

    What say you, fellow readers?



    I told you about this 3 weeks ago in a personal message via your contact form; there was no response from you so I thought I was crazy and half-screen-blind. Anyway!

    Indeed. You and about 100 others. I responded to most of you. More importantly, I fixed the color flash before finalizing the redesign. So thank you for your input, to which I responded.

    Alas, the fix has broken Firefox on long posts. Which was the point of this post.



    For the record, as you don’t mention it, the issue in Firefox (windoze only) is bug 215055. (No comments in the bug please !)

    I didn’t mention it because I didn’t submit it.

    Are you sure this is the same bug?

    The bug is described thusly:

    Content of tall pages is clipped and can’t be displayed if overflow!=visible

    This was the original symptom on my page, however it was fixed by adding a red background flash to the CSS.

    As I read this bug report, the problem has nothing to do with CSS, and no solution has been found. (I agree that it is probably a related bug. Maybe it even is the same bug. Hard to say.)

    If it was the same bug, then the color background flash wouldn’t have fixed it, and I could remove the color background flash and start all my blog posts with a link to the Firefox bug, so Firefox/Win users would know why they couldn’t read half the content on my site.

    If enough complained, the bug fix would certainly be fast-tracked.

    But that doesn’t seem fair to Firefox/Win users. And the color flash appears to solve the problem for Firefox/Win users. So I’m stuck with it (or another, better CSS hack) until Mozilla fixes this bug.

    Note that the bug is not present in Firefox for Mac. I guess the other hope is that all Firefox users switch to Mac OS.

    No, I didn’t think it was realistic, either (though it would be cool).



    Weren’t there a couple of suggested solutions to the red flash problem originally?

    Indeed there were. I implemented the best one, and it worked beautifully until I wrote a long post that got numerous comments. That fix, which should work in all browsers, is precisely what breaks Firefox when the page is longer than a few paragraphs with just a few comments.

    Hence this post.



    Good luck at the hospital tomorrow!

    FWIW, I didn’t have a routine test. I had a surgery that last five and a half hours. (Here’s a palatable photo, and by palatable, I mean you can look at it and not lose your appetite.)


    Jeffrey, it almost sounds like you found a bug but now you’re jumping up and down shouting about those insane Firefox people. “How could they let such a bug through and why didn’t they discover it before I did?!!!”

    No, just pointing out that I and two other developers spent half a day trying to fix a problem that shouldn’t exist, and implementing a solution that fixes Firefox’s problem while penalizing almost every browser user (including Firefox users). All of which is to say, this is a bug that should be fixed in the browser.

  15. I don’t believe this is a bug more than it is a rendering time-to-load issue. This bug has been around for years in Firefox that I’ve seen.

    When your content area is a different color than the body, it loads top down (body first obviously has a bg of red) which is why you get a red flash…as that is rendered before say the div with content which has a white background.

    Because the CSS files are pulled in parallel ( multiple http requests at once ) — one for the html, one for the main.css for example.

    The css could have the red loaded and applied as the html is still loading ( as is typically the case on pages with lots of content/comments ).

  16. Similar to @foozbar, surely the flashing red is not exactly a bug, as the #wrapper contains floated elements the height does not expand, so you use the overflow: hidden hack to fix this. Which, to my knowledge, is exactly that – a hack. I don’t really understand the hostility towards Firefox for not behaving as expected if you are using CSS hacks.

    I may be missing something here, but the only reason you had the issue was because you were using overflow: hidden. I presume the fact that containing elements don’t expand with floating children is intentional (and outlined by the W3C), as it is this way in all browsers.

    I may be wrong here, just voicing on the knowledge I have.

  17. Whatever the problem in Firefox is, it has nothing to do with how much actual HTML is on the page. I first noticed this problem when I zoomed the text (only) in Firefox on one of the blog longish comment threads here to something that is comfortably readable to me.

  18. @Joe Hoyle:

    The bug ‘A very long page cannot be displayed in full (in some cases)’ in Firefox 3+/Win (btw, another reader reported that the same bug appeared on FF/Linux, too, so it is not a FF/Win only problem, but probably FF/Win+Linux; FF/Mac is unaffected, though) was not triggered by Jeffrey using overflow: hidden; on the #wrapper element, but by using the perfectly valid overflow: auto;. For some reason, Firefox then ‘cuts’ the page at some point and the content below the ‘cutline’ is no more visible (screen).

    What I did? I created an exact copy of one of Zeldman’s long pages which displayed the bug, and then tried a CSS fix suggested by Rob in an earlier thread. I discovered that, indeed, when I applied overflow: visible to the #wrapper element, this fixed FF’s strange behaviour, and it started again to show pages normally, in full. After that, I tested if any other browser was affected by the change, and finally, I recommended the fix to Jeffrey.

    He implemented it later, and Firefox was OK, again.

    Unfortunately, what I did not notice, when I was testing the fix in FF/Opera/Safari, etc., was that after changing the overflow property of the #wrapper element to visible, all browsers started to show the ‘quick red flash’ behaviour, which Jeffrey described in this post. This flashing behaviour, you can see it now here (or in my first demo, with the FF bugfix applied).

    So, I fixed something, but I have un-fixed something else… :-( (Looks like nobody’s perfect…)

    Still, as Jeffrey said, “Better to show a full page in Firefox, even if it’s flashing a little in all browsers, than show half-page to Firefox users.”

    I would personally prefer to show full pages to Firefox users on Windows/Linux, and not to see any flashing of the background in any browser, and that’s why I tried to find yet another workaround for the new bug I’ve triggered by fixing the previous bug.

    Thus, the new fix, which I proposed after a few more hours of testing till almost 5 a.m. last night:)


    1) we keep overflow: visible for the #wrapper, which fixes the serious issue with Firefox 3+ on Win/Linux (when it doesn’t show the whole content of the pages), and then
    2) we fix the red background flash in all browsers by first loading a very small, centered, repeat-y GIF image of a matching color, applied to the body element (demo).

    Zeldman reports that my demo works very well for him in Safari/Mac, and flash is gone.

    And I will appreciate, if other readers can confirm (or the opposite) if the background flash in my demo is less noticeable (or not present at all) than in the current pages of

    And if the ‘GIF background fix’ works, indeed, then I’d suggest implementing it here, too. After all, we all use the Faux Columns method of Dan to imitate columns in CSS designs, so why not apply a small image to the body of the pages, which will make the annoying flash disappear? ;-)

    Finally, I’d like to repeat one more time that there exist probably a lot more solutions to the problem with the background flashing, but I suggested & tested just one, and that if someone can come up with a more elegant way of resolving this problem, then I’d suggest to Jeffrey to use the best one, of course! :-)

    * * *

    (later) @Pete: I tested your solution, too, with the difference that I specified min-height of 1000px for the #wrapper — when I used 400px as value, the top part of the Safari viewport did not flash, but the bottom one did! So I put instead 1000, and re-tested. For Safari 4/Win, this works very well, as far as I can see! On Firefox 3/Win things look well, too. I have also tested in Chrome 2 and IE7. Here’s the new demo based on your suggestion. I don’t think there is a page on, which is less than 1000px in height, and I don’t also think that we need to specify a larger value than 1000 (only a very large screen may display some flashing at the bottom of the browser).

    So, Jeffrey, looks like someone has found a more elegant solution, after all! :-)

    Take your pick now — use ‘min-height’ on the #wrapper element; or a small centered repeat-y GIF on the body; I have tested both and it appears both solutions work pretty well (but I think Pete’s is better). Remains to see what the other readers will report (I cannot test on all browsers and operating systems), then simply implement one of the solutions we proposed and problem with flashing is solved!

    And, as a bonus, you keep the Firefox fix, which will allow FF users to read full pages of your blog, too! ;-)

  19. Interesting topic.
    By the way, I see that in IE7 the first big red letter on the introduction (capolettera in italian, how do you call it in english?) is cut at the bottom, the GO button in the search form looks ugly, and there is a javascript error (this happens in any browser), because the function st_go() at the bottom of every page – something related with wordpress stats – is not found.

    In IE6 the right sidebar goes directly under the main content. I know we should not worry about ie6, but this is a very simple fix.

    May be those information can be useful, and I apologize if you already talked about it.

  20. (off-topic) When I mark a word in a comment like this:
    <strong>bold text</strong>
    …it doesn’t appear in bold afterwards, when the comment is published. I see in the main CSS file that strong> is disabled and appears like regular text. I presume, this is intentional — maybe because links are in bold always? I was just wondering… :) (/end off-topic)

  21. I see the same problem with IE7 as Alessandro: The Large capital letter at the beginning of the first paragraph is shaved in half, the user only sees the top half of it. In the span .drop, the following fixes that problem in IE7 (the em values for IE6 are a guestimate)

    padding: 0.25em 0.08em 0pt 0pt;
    #padding: 0.25em 0.08em 0.2em 0.00em;/* override for Microsoft Internet Explorer browsers*/
    _padding: 0.25em 0.08em 0.4em 0.00em; /* override for IE browsers 6.0 and older */


  22. @Alessandro:

    Thanks for writing and welcome to

    In IE6 the right sidebar goes directly under the main content. I know we should not worry about ie6, but this is a very simple fix.

    I could easily introduce hacks to my CSS that would move the sidebar where it belongs in IE6, but this is a site for web designers and developers, and in particular for standardistas, very few of whom are using IE6 as their daily browser (except perhaps when forced to in an office situation). A standardista forced to use IE6 at work, who uses Safari 4, IE8, or Firefox 3+ at home, will understand and accept that isn’t overly concerned with niceties of layout in a nearly ten-year-old browser whose bugs vis-a-vis web standards are legion and legendary. The One Ring was Isildur’s Bane, and IE6 is our bane (as Netscape 4 once was). While in most commercial sites, I and all of us still probably need to create a separate IE6 style sheet, or hack up our single style sheet with mind-dead “rules” that compensate for most of IE6’s tragicomic deficiencies, we don’t have to do that on *every* site, and I choose not to do it on this one, where I don’t have to.

    in IE7 the first big red letter on the introduction (capolettera in italian, how do you call it in english?) is cut at the bottom,

    I’ll need to tinker with that. To tell the truth, I’m less and less concerned, on my personal site, with coding the same simple element half a dozen ways to compensate for deficiencies in various older versions of IE across various Windows platforms.

    It should look good in IE7, though. I need to at least be less lazy about that one.

    the GO button in the search form looks ugly,

    It looks ugly to you. To me it is more beautiful than the breast of Venus. Different strokes.

    there is a javascript error (this happens in any browser), because the function st_go() at the bottom of every page – something related with wordpress stats – is not found.

    This happens in no browser of which I am aware. Perhaps there was a momentary time-out between the plug-in and the server. Or perhaps when we updated the stats plug-in, an old script did not get updated, and your browser reports this as an error. (As a developer, maybe you have turbo JavaScript error reporting turned on.) If I can reproduce the problem, we will fix it!

  23. @Michel, you tireless homme fantastique, thank you for toiling on my site while I and my bloody bandages made a tragicomic attempt at sleeping through the night.

    I would personally prefer to show full pages to Firefox users on Windows/Linux, and not to see any flashing of the background in any browser, and that’s why I tried to find yet another workaround for the new bug I’ve triggered by fixing the previous bug.

    I agree 100%. In fact I was seriously considering going back to overflow: auto, letting Firefox3+/Win (and Linux too, you say?) choke on half the content, and using personal charm and peer pressure to try to persuade a dedicated and supremely talented Mozilla engineer to fix this bug post-haste if such a thing is possible. (It may not be possible. Some bugs take forever to fix, as you know, even with the best engineers working as hard as they can.)

    Thus, the new fix, which I proposed after a few more hours of testing till almost 5 a.m. last night:)

    Monsieur, get some sleep yourself. No sense both of us spending time in the hospital! (Nevertheless, thank you.)

    I will look at your recommendations and Pete’s first thing this morning. Thanks so much.

  24. Hmm… Maybe we should not turn this post into a whole new wave of ‘support comments’, addressed to Jeffrey (although I have my share in this, too — see my ‘strong’ question above;-).

    My idea is: let’s keep focus on the current problem with background flashing (we already suggested two fixes, which aren’t bad at all). Once the problem is gone, I think that Jeffrey can write a new post, entitled maybe like this “Dear readers, help me make even more perfect!”. Then we’ll be able to freely suggest:

    a) add strong {font-weight: bold;} to the CSS [this will make text in bold again appear as bold, and not normal, as it is now -- at least, in the comments it so, now],
    b) suggest a fix for the dropping
    #sidebar for IE6 [although I personally think that it is time for us to leave IE6 unsupported],
    c) suggest all kinds of other fixes -- for the large capital letter at the beginning of all posts (visible in IE7 -- I can confirm this), etc. etc.

    But for now, let's maybe try to help with the flashing background problem; other small details can be fixed/discussed later, right?

    And I think if we overwhelm Jeffrey with questions, we won't help him recover speedily (and we all wish him to recover, soon, right!)... ;)

    What do you think? :)

  25. PS Looks like I forgot to close a CODE tag after the word strong in my previous comment. I clearly see that I need some rest (or more coffee). I’ll go get provide myself at least with one of these. But, Jeffrey, thank you for your kind words! :)))

  26. @Michel

    Sorry the for misunderstanding, I presumed overflow: hidden; was used, as a few weeks ago someone on Zeldman’s blog suggested using that. Cheers for clearing it up.

  27. The problem is now 99% fixed. The flash can still occasionally occur in some browsers, midway down a long page, while scrolling, but this is an edge case. Mostly the reddish-orange flash is gone, thanks to you, intrepid readers.

    @Joe Hoyle: I was using overflow: auto and had not set a min-height on the site as it did not seem to require one.

    The Firefox bug was not the flash of red content—as you say, and as I said myself, the flash was a consequence of trying to solve Firefox’s documented inability to show long content by using overflow: visible instead of overflow: auto, as readers Michel Bozgounov and Kyle Weems had suggested.

    This worked around Firefox’s bug but imposed a flash of red, and this trade-off was the topic my post was intended to describe.

    Pete of subsequently suggested using min-height to work around the color flash problem, initially suggesting a value of 400px. Michel, who apparently never sleeps, then implemented that suggestion, but with a min-height value of 1000px, in a demo he posted here.

    @Pete and @Michel, I’ve implemented your suggestion and given you credits in the comments on my style sheets:

    These styles will appear in a chapter of the upcoming Designing With Web Standards, 3rd Edition (which, for the first time, I’m co-authoring with Mr Ethan Marcotte), and if you’ll send me your postal addresses, I can make sure you get copies of the new book.

  28. @foozbar :

    I don’t believe this is a bug more than it is a rendering time-to-load issue. This bug has been around for years in Firefox that I’ve seen.

    The color flash was not a bug; it was expected behavior and a trade-off when I implemented an earlier solution to the actual documented bug of Firefox cutting content in half on long pages.

  29. @Paul of :

    I’ve implemented your IE7 values on the drop-cap; also your IE6 values (hey, why not?). Please check in IE7 and see what you think.

    (You also get a credit in my style sheets, which means readers of the next edition of Designing With Web Standards will be all up in your grill.)

    Ambitious helpers with access to IE6, feel free to check how the drop cap looks in that browser as well. (I’m not super concerned, but if it does look about right, so much the better.)

    Thanks, Great People.

  30. The red cap looks good now on IE.
    If interested, here you can see two screenshots of your homepage: on IE7 on IE6

    About the javascript issue I reported some comments ago, I thinks it’s probably the proxy of my office that filters all the urls in the domain and so my borwsers doesn’t have the script where the needed function is.

    So, your javascript is ok.

  31. Wow. Thank you, Jeffrey! :-)

    I don’t know what to say… I am touched! I will surely send you my postal address, and I’d be most happy to receive the book from you! Will it be too impudent from my part to also humbly ask you to autograph it, before sending? ;-)

    I am glad that I was able to help. (I read the first edition of your book, and I’ll be very interested to read the Third edition. Your book helped me become a better Web designer; I just returned you the favour now;-)

    And, as I think of it, aren’t we all Web professionals — developers, designers, information architects, CSS/HTML coders, etc. — aren’t we all supposed to help each other and make the Web a better place? And aren’t Web standards supposed to help us in this goal? :-)

    On a //sideline, this is one of the reasons why I was a bit saddened, when the news broke that W3C abandons XHTML 2 in favor of HTML 5, and suddenly so many people started assaulting some professionals, who prefer coding XHTML (and not HTML), and said things like “HTML is better than XHTML”, “XHTML is dead, long live HTML”, etc.

    We are all creative professionals. We should respect each other and not call each other stupid names and argue which standard is better, because this is not the way we should go. XHTML exists now, and it will exist in HTML 5, too, as well as HTML. XHTML style syntax will exist in HTML 5, too. We should stop worrying about XHTML 1, HTML 4 and HTML 5, and concentrate on learning & working together, towards a better Web!

    Thank you, Jeffrey, for the support for all of us, professionals, and for your article! :-)

  32. @Michel:

    I will gladly autograph the book before sending it to you. I agree 100% with your comments about helping each other as a community—for me it’s a defining aspect of our profession, and hugely (and agreeably) different from other creative professions in which I was employed before the web existed. In some of those other creative professions, secrecy was necessary at all times, and a borderline nasty competitiveness was required if you wished to advance in the field. I love the web for encouraging positive karma: the more you give away, the more you keep. The more you teach, the more you learn. The more secrets you reveal, the higher your professional status rises. It’s awesome.

    And in fact, I just wrote a comment on another post on this site explaining why the “I’m better than you” attitude that had emerged in some comments on the HTML5/XHTML debate saddened me and compelled me to write In Defense of Web Developers. Like you, I believe we are at our best when sharing.

  33. @Allesandro:

    You are wonderful!

    Thank you for your feedback and the screenshots. Hooray!

    The drop cap is now beautiful in IE7 and acceptable in IE6.

    (Sigh.) I suppose I should try to do something about the sidebar in IE6, but, to tell you the truth, I’ve forgotten the IE6 hacks necessary to “fix” the display in that sad old browser.

    I know (because I made the correction on dozens of sites, and I wrote about in two editions of Designing With Web Standards) that IE6 inexcusably doubles the width of a horizontal margin in a floated element. As floats, although not initially created for this purpose, are necessary for multi-column layout in CSS, what this means is that, alone among browsers, IE6 takes the correct value necessary for laying out the page, then doubles it, pushing elements that are supposed to be floated to the bottom of the page instead.

    IE6 also, as I too painfully recall, miscalculates the width of an element if any word or letter in a line within that element is italicized.

    Whereas most browsers include the additional room for an italicized letter or word when calculating the number of words to fit in a line before wrapping, IE6 calculates the width without italics, fits the words into the line, and then italicizes, breaking the line width and the layout.

    What makes this even more ironic is that Windows make italics narrower than roman text (whereas italics should be wider). So after word-fitting all text as normal, IE6 recalculates as if a proper text rendering engine were setting a true italic in place, thus breaking the layout. And then it sticks a narrow italic in the next line. It’s a trifecta of FAIL.

    Before Happy Cog grew, when I was doing most of the design and code myself, I knew every inconceivably wrong thing IE6 could do to good code, and I had a workaround up my sleeve for all of it. If I forgot a workaround, I could check positioniseverything, or Google, or Eric Meyer’s CSS-Discuss mailing list.

    But I don’t worry about IE6 any more. If a commercial project needs to support IE6, well and good—our agency has the skills to take care of it (and so do you).

    But on forward-looking personal projects (even retro-designed ones like this one), I’m more likely no longer to think twice about IE6 and its drawbacks.

    So I’m torn. A professional part of me wants this site to look swell in any browser. (Swell, not necessarily the same—in fact, most likely, not the same.) But the part of me that is tired of waiting for companies to catch up with what some of us have been doing for more than ten years thinks, eh, let the sidebar drop in IE6—who cares?

  34. …and raising doubts about the professionalism of the site and thus of the opinions it expresses.

    I thought the new design did that right out of the bag. >:D

  35. @Pete and @Michel,

    Actually, there is still a bit of red flash on longish pages or when connection speed drops—as it might drop, for instance, on a high-speed cable modem connection. (Such connections, used in millions of homes, are typically quite peppy, but suffer from intermittent periods of gapping and mini-outage. Home users accept this as normal. In practice, it means that every once in a while, you get to watch a page assemble itself, and if there are compromises in the CSS, you can see them.)

    This red flash bugs me more than long pages getting cut in half by Firefox, since I’m not responsible for Firefox’s bug, but I am responsible for my choice of CSS methods.

    What to do.

  36. I agree with your position about IE6.

    Unfortunately, I can’t forget the various IE6 hacks, because I work as web designer and developer in a very big italian company that for lack – or laziness – of system administrator still has IE6 as the default browser in the most part of its computers. So every intranet application we build needs to be almost perfect in IE6 too. I think it will take some years before we can forget IE6.

    But for non commercial projects, it’s definitely time to don’t worry about IE6 anymore. I like the way Stuff and Nonsense receives who visit their site with IE6.

  37. @Jeffrey, about the update to the post:

    My fear now is that the Firefox bug will not be fixed, as the primary page demonstrating the Firefox bug has now been Firefox-bug-proofed via CSS workarounds. This is always the problem with “fixing” browsers by changing CSS.

    Why don’t you save a copy of the page with a stylesheet without the fixes, and have a link to it here, so that Mozilla developers (or anyone else) can see the problem? I couldn’t spot it the bug, because I was first reading this post and the comments at home, where I use Linux, and hens no bug. When I got to the Windows machine at work, the page was already fixed, and I’m feeling like I have missed the show ;-)

    @Alessandro, this is a killer feature! You already started the trend, surely someone is already thinking about having low-fi version of his page for IE6 ;-)

  38. Alessandro:

    My friend Andy Clarke (head of Stuff and Nonsense) has already done what needed to be none. I would not advance the cause by copying Andy’s work. Andy’s work speaks for itself.

    By the way, Andy is a frequent and popular presenter at An Event Apart—folks can see him at our next event in Chicago.


  39. May be you are right, but I don’t see it as copying Andy Clarke’s work. I see it as implement with your irony and talent the great and funny idea of A.C.
    (not sure if my english is good enough here…)

    Anyway, it was just an occasion to share that great home page.

  40. I was going to say, Michel, that your demo page was working fine for me in the various browsers I tried, but it looks like you already got confirmation.

    Great job!

    Good idea, Gonzo, on preserving examples of the Firefox test page so that the Mozilla guys have something to confirm the bug with.

  41. As floats, although not initially created for this purpose, are necessary for multi-column layout in CSS, what this means is that, alone among browsers, IE6 takes the correct value necessary for laying out the page, then doubles it, pushing elements that are supposed to be floated to the bottom of the page instead.

    I may have a work-around for you in regards to floats. This doesn’t necessarily fix IE6’s issue with width, but it does make it easier (especially with a left to right main-content > sub-content layout that you have here) to work with cross-browser compatibility without having to deal with all the issues that resolve around floating objects (and clearing them).

    At Mindfly, where I work, we’ve discovered that inline-block works very well to get around some of our most sticky float issues, and Kyle (who helped earlier up on this project), wrote a great blog post about using them and getting rid of a mess of floating issues.

    To simply sum up, there are a few cross-browser issues with using display: inline-block, but luckily most of them can be fixed without the requirements of the Dean Edwards Script for IE6, or any large hacks other than changing each case to display: inline for IE7 and below. It at least lets you line up elements without having to deal with floats or clearing them.

  42. unit tests, unit tests, unit tests, unit tests….I don’t want to beat ya up too much but seriously UNIT TESTS! BTW the IE6 issue might be able to fixed
    by replacing margin with padding of the same value. In my experience
    this has also been forward computable with Op FF Sa. Check to see that your case supports this.

    I don’t have many issues when it comes to IE6. I use a null or reset rule in CSS and code in development with descendant selectors. Then unit test and remove redundancy top down. With all this design going on have we forgot to be programmers? I think we need a revival of programming rather than development in web apps. They are two different schools of thought.

  43. This may be part of the issue with your last post on the FF issue. I removed overflow:auto from the #wrapper and it worked just fine. Not sure if that is the issue or not, but it worked for me.


  44. OK,

    Looks like, after all, this became a more broad ‘support thread’. Then I’d like to chime in again and add a note about one more (very slight) inconsistency in the current design of

    In the sidebar, there’s the main navigation:

    * about
    * contact
    * subscribe

    When you are on one of these pages: ‘About’, ‘Contact’ and ‘Subscribe’, the styling of the link for the current page is supposed to be different. It is, in fact, different, but only on the page ‘Contact’ (letters are black, and the font-weight is normal, so the user knows that he/she is on the ‘Contact’ page).

    I’ve made a quick research and discovered the reason for this inconsistency:

    In the main CSS file, there can be found the following code block, which is behind the ‘magic’ that changes the appearance of the current link in the navigation:

    /* You are here - subnav */
    body#aboutpage li#about a,
    body#lopez li#contact a,
    body#syndicate li#xmlfeed a, li#essentials a,
    body#oldposts li#essentials a {
    color: #333;
    font-weight: normal;
    background: transparent;

    Notice the IDs: #aboutpage, #lopez, #syndicate, for the BODY of the three pages:
    and then let us check the body ID in the HTML source code.

    For ‘About’ page, it is:
    <body id="yak">

    For ‘Contact’ page, it is:
    <body id="lopez">

    For ‘Subscribe’ page, it is:
    <body id="home">

    Now also let’s check the code of the nav list:

      <ul id="depts">
        <li id="about"><a href="/about/" title="The secret's in the sauce.">about</a></li>
        <li id="contact"><a href="/contact/" title="Write to us.">contact</a></li>
        <li id="xmlfeed"><a href="/subscribe/" title="Subscribe to this site's content.">subscribe</a></li>

    Problem solved! You can now see the the code of the nav UL is correct. But the BODY IDs do not match the IDs specified in the CSS file — except for ‘Contact’ page, where the BODY ID does match! So that’s why on ‘Contact’ the styling is different on the nav link, but on the other two pags, it is not.

    So, to fix this small inconsistency, you can simply change the IDs to correspond correctly in the CSS code, or, you can change them in the theme’s HTML:

    In the HTML, the body ID for ‘About’ page should be changed to ‘aboutpage’ and for ‘Subscribe’ page to ‘syndicate’ (now they are incorrectly named ‘yak’ and ‘home’). After that, the links will correctly have different style, when you are on one of these pages, so that you know, where you are. Hope this will help! :-)


  45. @Michel:


    The body ids were correct when the redesign launched. The templates seem to have gotten banged up somehow since. Thanks for calling my attention to it. We will of course correct the body ids on these sub-pages.


    At this point we’re far enough off-topic that I’d say we’ve exhausted this topic. The topic was: Firefox has a bug in it. A sufficient number of people have now viewed the test page in Firefox and confirmed that the problem exists. We can’t provide a solution, but Mozilla engineering can. I hope they can do it soon.

    Honestly, I’m becoming sufficiently uncomfortable with the the temporary alternate CSS that I’m thinking of reverting to my original CSS—even if it means long pages are hosed in Firefox.

    (I wouldn’t feel this way if the alternate CSS solution were seamless, but it’s not; it’s frustrating to impose a visual penalty on everyone because of a problem in Firefox. If I wouldn’t do it for IE, I probably shouldn’t do it for Firefox, either. Of course, you never do it for the browser. You do it for the people who use the browser.)

  46. @Jeffrey:

    Why don’t you try an alternative solution? The one with the small GIF background, applied to the body? Maybe the flash will be less, then? Or maybe another, even better one solution?… :-)

    Please, compare one more time, on Safari and Firefox:

    This example uses GIF background ‘hack’ (my old idea):

    This example uses the min-height hack (currently used on

    When I scroll down the page and try to refresh several times, I think that the quick ‘flash’ is much less prominent in example #2 than in #3. At least, on Firefox.

    The number of Firefox users is quite high, and cutting the pages mid-way, is maybe worse than having a quick flash of the background…

    Worse case: serve the CSS ‘hack’ to Firefox users only. Serve the standard CSS to all other browsers. That still will be better than to not show whole pages to FF users…

    Then, at some point, maybe Firefox bug will be fixed and you’ll revert back to your original CSS… :)

  47. You’re welcome, Jeffrey!

    I even thought that you may try applying both fixes to the CSS — the ‘min-height’ one + the other, with the small GIF image — they can complement each other and help reduce the flash in all browsers even better… ;-) (just a random thought…) Or maybe someone will come up with even a better fix than these two, who knows?

    Finally, I’ll just add that I noticed in the navigation, now, the three links are marked correctly as current, when I go to one of these pages – ‘About’, ‘Contact’ or ‘Subscribe’, which means, your design is now even more perfect than before:) Glad I’ve helped, and I wish you a nice week! :-)

  48. Michel:

    I even thought that you may try applying both fixes to the CSS — the ‘min-height’ one + the other, with the small GIF image — they can complement each other and help reduce the flash in all browsers even better… ;-) (just a random thought…)

    A good thought. It seems to have worked. ;)

    Merci beaucoup!

  49. @Jeffrey:

    I’ve just tested: FF 3.0.11/WinXP and Safari 4/WinXP. I see no flash now, or at least, after the first time the pages has loaded (and some parts of CSS/images have been cached) the flash cannot be noticed at all — yes, it looks like combining the two fixes have removed the flash for good! :-)

    Cheers! I hope you’ll be able to sleep well, now! ;-)

Comments are closed.