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! ;-)

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!

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! :-)

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):
http://www.optimiced.com/web/2009/zeldman/index-2.html

This example uses the min-height hack (currently used on zeldman.com):
http://www.optimiced.com/web/2009/zeldman/index-3.html

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… :)

D’oh!

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.)

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 zeldman.com:

In the sidebar, there’s the main navigation:

Here
* 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,
body.cat-essentials 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:
about,
contact,
subscribe,
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:


<h2>Here</h2>
  <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>
  </ul>

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! :-)

Cheers,
M.

Thanks,
Seth

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.

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.

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.