Skip to: Navigation | Content | Sidebar | Footer

Weblog Entry

IE vs. Image Replacement

April 08, 2004

Sure, I admit it: there’s a glaring IE6 glitch on this site. I’ve known about it for a while, but I’m not going to fix it. Well, there are two glitches actually, and the second is a little more tricky. But let’s talk about the first.

The big red banner is displayed by image replacement on an h1. Since I built the site, hovering caused the infamous ‘flicker’ in IE (which is the second problem, but I digress again.) Then I interviewed Ryan Carver for WaSP, and took a look at his IE investigation, after which I applied his method to the banner, thereby eliminating the flicker for good.

Except doing so introduced a brand new bug no one had ever seen before. What it looks like: a piece of the content from the body is being duplicated, and briefly layered over top of the banner itself. It’s easier to just see it:

IE Bug!

I have no idea what causes it or how I’d go about isolating it, and I’m not even going to bother. Instead, I’m going to point and laugh, and leave it as-is. Just because it’s IE. And just because I can.

(because some make disclaimers mandatory: this ‘ignore it’ approach is to be taken for this site alone. mezzoblue caters to web designers, who should know better than to run IE in the first place. No, you shouldn’t penalize users for their choice of browser. No, this isn’t an attitude to take when doing commercial work. No, I don’t know whether I’ll have the fish or the chicken.)

Okay, so the second bug is something more problematic, because it does affect most everyone else. In certain instances, hovering over image-replaced links causes the link to blink out and back in as the image re-loads. Keeping an eye on the IE/globe ‘throbber’ up in the top right corner shows there’s some network activity happening as it does this, albeit very briefly; watching your outgoing packets confirms it. IE isn’t caching, but reloading (or at least re-checking) the image every single time, causing the flicker.

There’s an easy fix! I wrote about it six months ago! It doesn’t actually work!

Well, it does for some. But here’s something I’m noticing — even with that generous caching setting turned on, in some instances IE still causes flicker. Like, on this site for one. Like, allegedly, on the Sprites demos at ALA for another. Which really causes me to scratch my head, because I purposefully layered two sets of images over top of each other to eliminate the problem.

But no matter, due to the inconsistency and terrible difficulty in tracking it down I’ve started to suspect it has to do with a server setting anyhow. Well lo and behold, in the very post referenced above, a link posted by Blake Scarbrough to a discussion which I either never saw or don’t remember seeing points out some .htaccess configuration which may yet provide a fix. I haven’t touched the code, so I can’t vouch for it yet, but you can be sure I’ll give it a shot when I have the chance.

update: Since there seems to have been confusion about this, despite the disclaimer, you’ll note that the second problem (the one that actually is a real problem that should be fixed) I said just above I would look into and fix. And so I have. Provided you have caching turned on in Internet Explorer, the flashing problem should be alleviated. The .htaccess lines in the css-discuss thread linked above did the trick. IE still flashes if caching is set to ‘check every time’, but as explained in the entry from six months ago I also linked to, this is a developer setting that has to be manually turned on, so most users will not experience it. Flashing problem: solved. Original IE glitch I decided not to solve: probably solved too. Onwards.

Reader Comments

blakems says:
April 08, 03h

I did change the .htaccess file as outlined from that discussion and it did work on the site I was working on. However I did switch to using pixy’s updated rollover method later and it worked as well.

April 08, 04h

The reason for the flicker seems to be because your server seems to think that the image needs to be redownloaded each time the mouse goes over it.

Here’s a trace in IE 6 (with XPSP2):

GET /i/h-main.jpg HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.40301)
Connection: Keep-Alive
Cookie: style=null

HTTP/1.1 200 OK
Date: Thu, 08 Apr 2004 23:16:08 GMT
Server: Apache/1.3.29 (Unix) mod_auth_passthrough/1.8 mod_gzip/ mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.5
Vary: Accept-Encoding
Last-Modified: Thu, 18 Sep 2003 19:16:10 GMT
ETag: “4d01e6-6c09-3f6a047a”
Accept-Ranges: bytes
Content-Length: 27657
Keep-Alive: timeout=5, max=134
Connection: Keep-Alive
Content-Type: image/jpeg

Trace from IE plug-in ieHTTPHeaders -

Your server *should* be returning:

HTTP/1.1 304 Not Modified

In Mozilla/FF, there isn’t flicker because the Moz engine doesn’t it doesn’t seem to check with the server to see if a new image needs to be downloaded.

This issue can be caused if you have “cache expire” set to something like “immediately” on your server.

(I use IIS exclusively, and found this fix to work for me on every site I’ve worked on. I have no experience with Apache, so I don’t even know if this is a setting that can be easily changed.)

April 08, 04h

I posted the wrong header strings. Here’s the correct one showing the jpg being re-requested and re-downloaded each time the mouse goes over it in IE:

GET /i/h-main.jpg HTTP/1.1
Accept: */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; .NET CLR 1.1.4322; .NET CLR 2.0.40301)
Connection: Keep-Alive
Cookie: style=null

HTTP/1.1 200 OK
Date: Thu, 08 Apr 2004 23:27:53 GMT
Server: Apache/1.3.29 (Unix) mod_auth_passthrough/1.8 mod_gzip/ mod_log_bytes/1.2 mod_bwlimited/1.4 PHP/4.3.5
Vary: Accept-Encoding
Last-Modified: Thu, 18 Sep 2003 19:16:10 GMT
ETag: “4d01e6-6c09-3f6a047a”
Accept-Ranges: bytes
Content-Length: 27657
Keep-Alive: timeout=5, max=150
Connection: Keep-Alive
Content-Type: image/jpeg

April 08, 04h

That ugly “random piece of the page showing through” thing is what I mention as “distortion” in my article, and claim no responsibility for. However I just stumbed upon a way that seems to avoid both flicker and distortion. This may or may not be the same as Pixy’s updated method.

See the Update at

As for the server techniques, regardless of whether the server returns 200 or 304, the browser shouldn’t even be talking to the server on rollover.

Simon Boyle says:
April 08, 04h

I’ve bumped into a similar IE content duplication problem this morning at: and (Scroll to the end of the page to see magically duplicated content. Mysteriously, inserting empty div’s changes the content duplicated. And after multiple visits, IE crashes.

Porter says:
April 08, 06h

Dylan, according to what you posted in #3, IE is not sending an If-Modified-Since header in its request, so there’s no way the server could possibly know it should send a Not Modified response.

Dave, perhaps a silly question, but why not place the background image in the h1 instead of the link? Fixes the flicker/reproduction problem just fine here.

Lach says:
April 08, 06h

Hah, that’s about as weird as the random IE bugh on my site. Every so often, words are duplicated on it. Every word that ends a line is duplicated on the line below. Only in IE5, afaik, and only some of the time, and only in some copies.

IE bugs are fun!

dan says:
April 09, 01h

I added the following to my .htaccess and it fixed the problem for me:

BrowserMatch “MSIE” brokenvary=1
BrowserMatch “Mozilla/4.[0-9]{2}” brokenvary=1
BrowserMatch “Opera” !brokenvary
SetEnvIf brokenvary 1 force-no-vary

radu says:
April 09, 04h

“If your design doesn’t work in at least IE5+/Win and Mozilla (run by over 90% of the population), chances are we won’t accept it.”


“Just because it’s IE. And just because I can.”

is this the same dave?

April 09, 05h


> As for the server techniques, regardless of whether the server returns 200 or 304, the browser shouldn’t even be talking to the server on rollover.

Why do you say that? The server response includes no Expires header, so the client has no way of knowing how long its cached copy is valid for. If it hides the image and displays something else, and then attempts to show it again, it’s not unreasonable to ask the server if it’s still up to date.

Most flickering rollovers in Internet Explorer can be fixed by setting an appropriate Expires HTTP header.

Levin says:
April 09, 05h

A great tool to look at cache-related headers is the Cacheability-Engine here:

KJC says:
April 09, 05h

Dave – have the chicken!

Ray McKenzie says:
April 09, 07h

If the larger type is selected (from style switcher) the header does not duplicate body content. The red flicker is still there…but no body content duplication. (IE6 XP)

April 09, 07h

> If it hides the image and displays something else, and then attempts to show it again, it’s not unreasonable to ask the server if it’s still up to date.

I see your point. But as far as I know, ie6 is the only browser that does this.

Porter says:
April 09, 07h

Jim, what Ryan was talking about in #4 is that since nothing is being done with the image on hover there is no reason the browser /should/ be going back to the server to see if it’s been changed.

Jim H says:
April 09, 09h

I dont use IE that much but I have noticed that the navigation is unusable in Opera (7.3), but I read somewhere that you know of this issue. Its annoying but I can live with it.

It basically shows the drop down box to the left of the content area, or nothing at all.

Ollie says:
April 09, 12h

I’m dying for someone to get to the bottom of the rollover “flicker” bug in Internet Explorer. It has provided major obstacle to implementing many of the tidier CSS driven ideas into the commercial sites we build at work.

Below are some observations from the hours I have spent trying to isolate the dreaded flicker. Excuse any statements of the bleeding obvious, and keep in mind my methods for gathering these points have been less than scientific:

• Occurs when background images are used in conjunction with :hover, possibly also triggered by JavaScript used to imitate this effect on an element other than a link (“A”).

• Images are likely to flicker when a number of links share the parent with the background image. The more links the more flicker (mostly, sigh!). As, for example, in navigation menus constructed from unordered or definition lists. Flicker occurs when mousing from one link to the next.

• Only appears to be a problem in IE 6. Exact same page has no problem in IE 5.

• More likely to be triggered when visible link text is overlapping a background image, or at least when the parent element of the link text has a background image applied.

• Is not a consistent problem on every PC despite matching browsers and test web page. Processor speed could be a factor - not sure.

I’ll hungrily consume the links mentioned here shortly and test them out when I get back to work. Happy Easter!

In the meantime I have a possible answer to at least some of the duplicated content bugs mentioned here. I saw a similar thing happening and managed to pin it on empty DIVs in the page:

<div> </div>

This may not be the issue here but I hope it helps someone out there.

April 10, 02h

Dave, I’d be interested in seeing the percentages of browser types used to view your site, if you have access to such stats. I’ve found - - that for general purpose sites, there’s a ~95% slice going to the various IE flavors. Does Mezzoblue have a significantly different spectrum?

Dave S. says:
April 10, 03h

Michael, since you asked – stats for this site (and only this site) since the beginning of 2004:

IE - 18.98%
NetNewsWire - 16.52%
Mozilla - 15.89%
SharpReader - 7.35%
Netscape - 6.05%  
FeedDemon - 5.82%
Safari - 4.36%
NewsGator - 2.83%
(unknown) - 2.26%
Opera - 2.25%

And then a ton of low percentage bots, newsreaders, and other various unknowns.

Ben says:
April 10, 03h

I stumbled upon CSS Zen Garden while looking for CSS inspiration. By doing so I opened up a world of linked websites. I also gained rapid insterest in Mozilla, and have now become used to frustration over the pathetic CSS support in Internet Explorer.

What is Microsoft thinking? IE 5.5 for Mac is marginally better than IE for Windows in CSS support, but still has some major bugs to work

Until Microsoft realises that Internet Explorer truly does suck, it will always be fun to mock this decrepit program. Generally, there are ways to make a page browser-compliant. I hope that when IE for Longhorn is released, Microsoft will become aware of the battle between developers and users.

Either that, or web developers around the world should start a war against the use of IE. Rid the world of the bane of CSS design! A site that enforces the use of Mozilla or Opera. A site that will convert thousands from the Dark Side daily.

I call upon developers everywhere, instigate revolution!

Jadwigo says:
April 11, 01h

The duplicated texts usually appears if you have some floated divs inside other floated divs with a fixed width…

Those divs are not larger than the containing div in normal/nice browsers because only internet explorer doubles the margins (

It seems that internet explorer handles the overflow somehow buggy.

Hope this makes sense, it’s not a fix or anything, but somehow if you make sure that the nested divs have the right size the duplicated text disappears.

DarkCryst says:
April 11, 03h

I use both Firefox and IE6 to view this site on occation, never had this problem in IE, ever.


I have experienced wierd disapearances of DIVs that are absolutely positontion in relative elements tho (they actually just disapear.. its weird).

jgraham says:
April 11, 03h

Why are those stats a load of crap? It’s pretty clear they haven’t been filtered a lot but nevertheless they sound plausible:
50% of visits are from web browsers. That’s pretty low but not absurdly so given that people who syndicate the site are probably checking once an hour or so for updates.
The percentage of non-IE browsers are high compared to th general population. This is entirely expected and, to be honest, I’m surprised there are so many people visiting who actually use IE. People what are you doing?
The order of the alternatve browsers is broadly consistent with what you would expect. I’m not sure that Opera isn’t a bit low which suggests that maybe the analysis occasionally misidentifies Opera. Of course maybe people who read Dave are also more inclined toward other browsers for some reason (lots of possibilities, little chance of listing any without being flamed by at least one Opera user :) )

To all the people questioning Dave for not bothering to fix the IE issues:

If you use buggy software, you can expect to be affected by bugs.

It *is* Dave’s responsibility to make the site accessible, that is to make the content avaliable regardless of which browser is used. That’s the responsibilty shirked by people who design for a specific browser. As far as I can tell, this problem doesn’t prevent access to content.

It *is not* his responsibility to spend his life hacking around the deficiencies of poor software.

It’s in Dave’s best interests to have the page render attractivley in all browsers. By having an attrctive, well coded, site he maintains hs reputation as an elite web designer. However if he deems that the n hours it could take to track down the IE issue and maybe find a workaround would be better spent doing something else (like, y’know putting the laptop down and spending some time with his wife ;) ), he has no *responsibility* to fix the issue.

The correct ‘fix’ for this problem (and many others besides) is a fix in the source code of Internet Explorer. If you’re using unsatisfactory software you have the choice of complang to the vendor until it is fixed or switching products. If you put up with buggy software and expect everyone else to go out of their way to make things work for you, what incentive does the vendor have to produce good software?

mitch says:
April 11, 12h

those stats are a load of crap

mitch says:
April 11, 12h

they make roughly 80% for a start, and i dont see 20% as a low percentage of bots…. or do you get 20 different bots crawling your pages? ha!

for most sitesin the same genre it goes..

MS Internet Explorer

just to make sure ill be pointing my traffic anyliser at your site for the next month

Sergio says:
April 12, 02h

I find Dave’s stats very interesting, and enlightening as to what the hardcore CSS/Standards crowd is wearing in the browser area.

These are the stats for my site ( ). I post them to provide a point of comparison. We have different target audiences. My crowd has a high percentage of tech-oriented people, but also lots of casual visitors with no interest in web design or the like.

MS Internet Explorer 60.7 %
Mozilla 24.8 %
Safari 5.5 %
Unknown 2.5 %
Opera 2.3 %
Firebird 1.8 %
Netscape 1 %
Galeon No 0.2 %
Konqueror 0.1 %
UP.Browser (PDA/Phone browser) 0.1 %

These are the Operating System stats:
Windows 84.9 %
Macintosh 8.9 %
Linux 3.3 %
Unknown 2.2 %
FreeBSD 0.5 %

These are not broken down by version, but you get the idea.

April 12, 10h

I visit the Site mezzoblue frequently. And I saw the problem with the image replacement in the header. Now I see that the trouble is gone.
But what about accability. I have seen many solutions about image replacement.
I mean is this solution now save for screen readers and text browsers.
Thank you for your statements.

April 12, 10h

The stats aren’t helpful because those feed readers often show the page using IE as their renderer. I use IntraVnews, which brings the RSS feed into Outlook. I’m sure Outlook isn’t going to show up as a % of browsers.

But back to the real issue - did my post about the non-caching image solve the problem?

Dave S. says:
April 12, 11h

Those stats are straight out of my stat aggregator, but they’re only the first page. There are a bunch more below the threshold at 2% or less, which I’d assume add up to 100%, but I wasn’t going to bother listing them because most of those were bots and newsreaders. 20 bots crawling my pages? Way more. There have been 379 unique user agents/bots in the past week alone. Let me sample a few: Googlebot, Python urllib, NewzCrawler, Liferea, Drupal, kinjabot, Abilon, W3C_Validator, curl, apple 1.1, Botswana v0.1, msnbot, Feedster Crawler… and the list goes on.

Anyway, the second of the two problems, the bigger problem, and the one I said in my original post I was going to fix, has been fixed. The code from the link referenced - - when added to my .htaccess file did the trick. Note: it only works when IE’s caching is set to ‘Automatically’. Setting that to ‘Check Every Time’ still flashes; as I said above, it’s a developer setting that you have to manually turn on, so it’s not something to be too concerned that users will have enabled.

(The first problem may be fixed too, for that matter.)

Scott says:
April 12, 12h

The last time I was here, I noticed the header image flicker and reload issue (IE 6, Win2K) - and the strange “duplicate body” copy would appear in place of the image momentarily.

The flicker was affecting the nav (about / weblog / contact) as well, but both seem to have either disappeared or have been fixed since.

A friend of mine suspects third-party browser plug-ins may relate to this strange cache behavior. One would assume if the browser is making a request on a hover etc., the problem is with the browser and not the server.

Miriam says:
April 12, 12h

“Setting that to ‘Check Every Time’ still flashes; as I said above, it’s a developer setting that you have to manually turn on, so it’s not something to be too concerned that users will have enabled.”

If only that were the case! It seems like every computer on which my client checks their site, there’s a flicker because that machine’s on “check every time.” It looks like at this point I’m going to have to redo all of the menus… probably with sprites. Yick.

April 14, 02h

chriszs, I find the opposite of what you said to be true. Yes IE is fast, but its speed comes and goes in almost in a spastic pattern, a lot like Windows itself. Opera, while perhaps a little slower than IE at its fastest, are usually more consistent in its speed.

April 14, 06h

Every month when I read my statistic I hope that the old browser are gone. But sometimes I see 10% of netscape 4 browser. Honestly I think that browser are only used from people how what to check your side.

chriszs says:
April 14, 09h

I’ve used Opera, Mozilla, and Internet Explorer all extensively (I mean months of each) and I’m currently using IE for 2 reasons:

1. All the people who design for IE, but not anything else.
2. Because it feels more responsive. Despite Mozilla and Opera’s claims of being faster IE feels lighter on it’s feet than either, and when it comes to browser speed perception is reality.

Paul D says:
April 15, 02h

Chriszs, I’d be curious to know what OS and platform you’re on. I agree that Mozilla is a little slow, because it’s really an advanced XUL platform with a web browser inside it (much like Windows Foghorn Leghorn’s XAML browser will be in four years).

But Firefox, using the Mozilla rendering engine, is certainly no slower or less snappy on my machines than IE. What’s more, you can easily download optimized builds for your processor. A P4 or Athlon-optimized Firefox build will run circles around IE, which is compiled only for the old 386 architecture. Check out for some of these custom builds.

Opera’s advantage seems to be its fast start. A cold start only takes 2 seconds on my machine, quicker than IE, even though IE runs in the background.

Anyway, after having my whole network infected with Nimda thanks to an IE/ActiveX bug, I’ve sworn off Microsoft. I’m running Linux at home, and my next machine will be a Mac.

chriszs says:
April 23, 01h

Vinnie & Paul:

I currently run XP on a 2.6 Ghz P4. I tried Firefox twice and both times it crashed, though that was probably when I was using 2000. Hmm, maybe it’s time to try it again. Thanks for the tip on the customized builds.

April 23, 06h

To Dave and Sergio:

Thanks for the glimpse at those stats guys. It’s very interesting to see the pretty drastic differences between the stats of differently-oriented sites. Seems that everyone who’s at all computer-proficient beyond just knowing how his programs work - people who take active interest in computers - are moving wholesale to IE alternatives. And their families and friends are probably following suit if they’re any good at explaining things - I know my circle of F&F are. :D

Basically, now more than ever, us web designers need to keep solidly in mind who our target audience is, especially when we’re pondering whether to spend all that time on that blasted IE/Win hack or just to say “screw IE”.

Shame that there’s no realistic way to have a site that would report on the stats of various different types of sites, like the spread we had here… unless it was some sort of community-fed aggregate. Hmmm….

April 25, 10h

I got many emails from users for quite some time now regarding this problem on on of my sites but I didn’t understand what they wanted as my system runs IE 5.5
When I upgarded to IE6 now I saw this problem and fixed it. The only thing is I needed IE5.5 is to test how is flash running on old browsers since it is differnt that IE6.

R. Hawthorne says:
May 04, 09h

I had the same problem with the flicker on a site I am building for the company I work for.

I downloaded a program that let me review the http header and discovered that IE6 was reloading those images each time.

I got our support implement that server fix, which is recommended to stop the flicker. It worked when put into the httpd.conf file. But didn’t work in the .htaccess file.

Brad Bice says:
May 18, 09h

.htaccess, httpd.conf, IE cache tweaking….none of it works.

I thought perhaps that one of these solutions would work and at first it seemed they did.

However, on a site I am developing I am making use of small pop-up windows that average 500-600px wide by 300-600px tall. When opened, this causes every single image replacement background to flicker over the whole page.

Even after closing the window, mousing over any image replacement background causes it to flicker.

I would have liked to say case-closed on this but the fact of the matter is that it is still a major issue.

May 30, 04h

That pesky image flicker!!

To clarify:

* only affects IE6 (not IE5/5.5)

* only affects CSS background-images which are influenced by some dynamic effect on the page (these are numerous and are not just hovers)

* is especially persistent when IE’s cache settings are “Every visit to the page” (a common developer’s setting)

* the “force-no-vary” server configuration does not fix the flicker for the above setting.

I added the following lines to my apache conf file:

ExpiresActive On
ExpiresByType image/gif A86400
ExpiresByType image/jpeg A86400
ExpiresByType image/png A86400

And thenI tuned on the apache module “mod_expires”.

That fixed it good.

The configuration above forces image files to persist in the browser’s cache for one day (86400 seconds).

If someone wants to test and improve this then go ahead. I’m no server expert…

August 05, 07h

I have noticed some complaints on other forums (strangely not here) about the image flicker solution (changing the server settings) not working.

I didn’t work for me, but I figured it out.

On my testing browser, I had press Tools->Internet Options->Delete Files (Delete All Offline Content).

Then, after a refresh, the images stopped flickering.