Internet Explorer v8 and Opacity Issues

A great WordPress plugin jQuery-lightbox (JQLB), used to provide animated slideshow-like viewing of images in a post seemed to be having some undesired behavior on sites viewed with Internet Explorer (IE) v8 – the plugin’s jQuery based javascript was unable to successfully set the opacity of an “overlay” <div> it created in process of showing images. All worked fine in Firefox (FF) and IE v9 but would fail (though not all the time) in IE v8 (unable to test IE v7 but it may also have similar issue). Some more testing seemed to confirm that all versions of the JQLB plugin were affect as were all versions of jQuery, but the issue only affected Windows 7/IE v8. 

Some background: When invoked JQLB’s jQuery javascript will create a <div class=’overlay’>, set its height and width equal to the page size, set the background color to black, and absolutely position it to top:0, left:0 so it covers the entire page. It also sets the <div> opacity to 80% to give a transparent affect so the underlying page is still partly visible.  On some pages and using IE v8 the affect failed and there would be no opacity with only a completely black background.

Using Firebug in FF and Firebug Lite in  IE I could see that jQuery was correctly setting css for the opacity setting per browser,

  • Firefox: opacity: 0.8;
  • Internet Explorer: filter: alpha(opacity=80); zoom: 1;

Inspecting the overlay <div> I tested some possible css culprits – position: absolute, z-index: 90;  but changes didn’t yield any different behavior with opacity. Using different versions of the JQLB javascript code or jQuery libraries didn’t help either.  Taking advantage to the great TryIt tool for testing css over at W3 Schools I eventually found that the issue seemed to be a bug, perhaps minor, in IE v8:

  • Opacity setting fails on a <div> when css height > 4096px (and IE v8/Windows 7)

This issue may not affect most pages but on a image heavy blog page or one with a healthy comment thread it may not be so rare to have page height greater than 4096px. Here is a sample page that sets a <div> with height: 41oopx and a couple of sample pictures. If you click on the picture JQLB will do its stuff – if using Windows 7 and IE v8 you’ll see that opacity fails on the overlay.

I’ve submitted code changes to the plugin’s author for possible inclusion in upcoming release. Below are not the specific changes but I figured I’d include some general code to account for this behavior and allow for a maximum <div> height : 4096px.

Using the browser feature testing suggested by jQuery and function provided at lets check for IE8,

function ie8Check () {
        var isBuggy = null;
        if (document.createElement) {
          var el = document.createElement(“div”);
          if (el && el.querySelectorAll) { el.innerHTML = “<object><param name=\”\”></object>”;
               isBuggy = el.querySelectorAll(“param”).length != 1;
       el = null;
      return isBuggy;

jQuery based javascript to get the document page size and check for this bug (set max height = 4096),

function getPageSize() {
     var pgDocHeight;
     pgDocHeight = jQuery(document).height();
     if (ie8Check() && pgDocHeight > 4096)) {
          pgDocHeight = 4096;
     return new Array(jQuery(document).width(), pgDocHeight, jQuery(window).width(), jQuery(window).height(), jQuery(document).height());

Return the actual document height since it will most likely be needed.

Example below assumes the user has scrolled to a location and clicked on an image that launches to main part of the JQLB javascript. When the IE v8 bug is true, it attempts to account for where the user is scrolled to within in the post and set a new top offset for the overlay <div> relative from the page top. Arbitrarily picked 1000px above the current top which then allows for 3096px below. Additional check for when user is near the bottom of the page, ie. < 3096px to end of page,

function setOverlayTop() {
     var arrayPageSize = getPageSize();
  var arrayPagePos = getPageScroll();
     var offsetTopTrigger = 1000;
     var maxBugPageSize = 4096;
     var offsetBelow = maxBugPageSize – offsetTopTrigger;
     var newTop = 0
     var Left = 0;

      if (ie8Check() && arrayPageSize[1] == maxBugPageSize) {
               if (arrayPagePos[1] >= offsetTopTrigger) {
                   newTop = arrayPagePos[1] – offsetTopTrigger;
                   if ((arrayPageSize[4] – (arrayPagePos[1] + offsetBelow)) < 0) {
                       newTop -= (arrayPagePos[1] + offsetBelow) – arrayPageSize[4];
      jQuery(“#overlay”).css({ top: newTop + ‘px’ , left: Left + ‘px’, position: ‘absolute’, z-index: ’90’});

  jQuery(“#overlay”).hide().css({ width: arrayPageSize[0] + “px”, height: arrayPageSize[1] + ‘px’, opacity: ‘0.8’ }).fadeIn(400);


function getPageScroll() {
    var xScroll = 0;
    var yScroll = 0;
    if (self.pageYOffset) {
        yScroll = self.pageYOffset;
        xScroll = self.pageXOffset;
    } else if (document.body) {
        yScroll = document.body.scrollTop;
        xScroll = document.body.scrollLeft;
    return new Array(xScroll, yScroll);

The bug reproduced on: Windows 7 – IE v8
The bug didn’t reproduce on: Windows XP/2003 Server/2008 Server – IE v8
The bug didn’t reproduce on: IE v9
The bug didn’t reproduce on: Window 7 – IE v8 after downgrade from IE v9

Overall it’s a minor issue and since its doesn’t reproduce in IE v9 hopefully it will become moot a issue as the percentage of IE v8 users diminishes over time. Though as of 5/2011 I think most sites are seeing approximately 18-25% IE v8 while IE v9 is around 5-8%.

Your comments are welcome.