I encountered a similar issue with IE8. To fix it, I adjusted the opacity of the DIV using JavaScript before triggering the fadeIn() function:

$('.overlay').css('filter', 'alpha(opacity=40)');
$('.overlay').fadeIn(500);

In this case, I was working with a regular DIV element and not a transparent PNG.

If you're looking for a simple and effective solution, this might be just what you need (it certainly works for me). The issue of alpha transparency in Internet Explorer can sometimes cause problems when the parent element has a completely transparent background.

The workaround presented here involves adding a nearly transparent div as the first child within the container. By positioning it absolutely and making it almost invisible to the eye, this div acts as the background for all other content inside the container.

This prevents IE from displaying unsightly black pixels or areas when changing opacity settings on the canvas. Here's an example using a 100x100 image:

<div id="mycanvas" style="display:none;">
<div style="position:absolute; background:#FFF; display:block; filter:alpha(opacity=1); opacity:0; width:100px; height:100px;">
</div>
<img id="myImage" src="example.png" width="100" height="100"/>
</div>

To fade in or out the image with jQuery:

$("#mycanvas").fadeIn("slow", function() 
{
    setTimeout(function(){
        $("#mycanvas").fadeOut("slow");
    },2000);
});

You can also simply use:

$("myImage").fadeIn("slow");

This approach is compatible with VML/SVG (Raphael) and other elements with alpha transparency, without requiring any changes to your JavaScript code. It's a neat trick that only affects Internet Explorer, leaving other browsers unaffected.

I hope this helps!

It can be challenging to determine without seeing the specific code, but one thing to keep in mind is that Internet Explorer (IE) often struggles with applying fades to elements that have a position: relative style. I recommend checking if the elements you are attempting to fade, either directly or through their parent elements, have position: relative applied. This could potentially resolve the issue. Wishing you success in resolving this matter.

When faced with a similar issue, I managed to resolve it to some extent by following the advice given by @Erwinus. While this approach significantly improved the appearance of the halo, there was still a noticeable black aura present.

To completely address the problem, I decided to add a background to the image itself:

#slideshow img{background:#FFF url("image/background-of-slideshow.jpg") no-repeat -15px -35px;}

This simple adjustment worked like a charm. I saved it in my iefix.css file, which is called using conditional comments. It didn't require any additional HTML and actually produced a smoother fade effect compared to the original solution.

Keep in mind that while this fix worked well for me, it may not be suitable for all scenarios. However, it's worth considering as an option if you encounter a similar issue.

One workaround for this issue is to utilize jQuery to set the opacity of elements before animating them. It seems that there are some issues with jQuery (pre-1.4) detecting opacity when it's originally set via CSS. By setting the opacity using both CSS and jQuery, you can ensure proper functionality in IE. This technique also applies to handling the display none property.

For example:

$('#element').css("opacity","0").fadeIn("slow");

Source:

So, I encountered a problem with this code and couldn't find any solutions that worked online. It was really frustrating because it seemed to work on the W3C site: http://www.w3schools.com/Css/css_image_transparency.asp, but when I tried it in my development environment, it failed.

The code I had was:

<script type="text/javascript>
       $(document).ready(function() {
        $('.disabled').fadeTo("slow", 0.33);
  });
 </script>

And the corresponding markup:

<a href='homestarrunner.com' class='disabled'>
<img src='http://www.w3schools.com/Css/klematis.jpg' /></a>

It worked fine in Firefox, Chrome, and basically every other browser except for IE8.

We eventually discovered that IE8 wasn't executing the script properly when running locally. Once we moved the code to a webhost, everything functioned as expected. It's unclear why IE8 behaves this way, but it just adds another reason for developers to have issues with IE.

Maybe it's just me.

Hey @LoveMeSomeCode, I can't reply directly to your post because stackoverflow thinks I need a certain amount of reputation in order to respond - how frustrating! I believe this is due to a pesky feature that comes with IE8 called "compatibility view," which is even more bothersome than the mode itself.

I've noticed some strange behavior when viewing the website I work on in IE, and after investigating, I found out that IE8 has a default setting that forces all local pages to display in compatibility view. This happens regardless of the document declaration or markup strictness. IE8 automatically uses compatibility view for all intranet pages (and possibly localhost as well).

To fix this issue, go to Tools > Compatibility View Settings and uncheck the box that says "Display intranet sites in Compatibility View."

I have no idea why this setting is enabled by default, but it has been causing a lot of trouble in terms of isolating the problem and instructing others on how to resolve it.

I'm having trouble with this unreliable web browser.

If you're dealing with Internet Explorer, remember to use .animate({opacity:'hide'}) instead of .animate({opacity:0}).