Yeah, sounds like something Robin the Boy Wonder would shout to Batman in the campy 60’s TV show.  But, no I’m talking about the “Promo Slider” plugin for WordPress.  It’s a pretty neat plugin but it has one annoying problem!  If you set the slider image to scale by percentage and have the “promo_slider” element adopt a height set either in percentages or “auto” and the page is lengthy and you’re scrolled down reading it will suddenly JUMP back up to where the slider is.  I haven’t checked on Internet Explorer, but it definitely affects desktop Webkit browsers (Chrome and Safari).  It doesn’t seem to affect mobile Webkit browsers nor Firefox. I figured since the promotion slider only works if you’ve got your javascript turned on I could look to javascript for a fix.

My solution:

  function setSliderHeights() {
    var sliders = document.getElementsByClassName('promo_slider');
    for (var s=0; s < sliders.length; s++) {
        var images = sliders[0].getElementsByTagName('img');
        var newHi = "auto";
        for (var i=0; i < images.length; i++) {
            if (images[i].offsetHeight != 0) {
                newHi = images[i].offsetHeight+"px";
            }
        }
        sliders[0].style.height = newHi;
    }
  }

  if ( ('ontouchstart' in document.documentElement==false) && (typeof document.documentElement.style['WebkitBorderRadius'] == "string") && document.getElementsByClassName('promo_slider').length > 0 ) {
      window.onresize = function() {
        setSliderHeights();
      }
      window.resizeTo(window.outerWidth,window.outerHeight-1);
      window.resizeTo(window.outerWidth,window.outerHeight-0);
  }

The “setSliderHeights()” function goes through all the images used in the slider looking for one that doesn’t return an offsetHeight of zero, then sets the slider box to that height. This assumes your slider background images all will use the same height.

Since this doesn’t affect mobile Webkit browsers there’s a detect for “ontouchstart” to rule them out, and then the second part checks for the existence of “WebkitBorderRadius” (this could be any Webkit proprietary style, I just picked one). You could also check for Webkit in the user agent string instead, but then you won’t capture a browser that is spoofing the UA string.

The third part just checks that the blog page actually HAS at least one promo_slider element on it before we go to the trouble of trying to fix it.

Ok, so if it determines you’re using one of the offending Webkit browsers we attach our function to the window.onresize event, which means every time the window registers a resize the slider box height gets recalculated. We can’t attach it to the onload event because the images are initialized and scaled too late and we’ll always get a height of zero. So, the next little part forces a window resize by changing the height of the window shorter by 1 pixel and then back to where it was. If you’re watching for it you can see Safari actually does it, Chrome blocks “resizeTo” from actually changing the window size but still registers the event so the resize on the promo still works.

This is obviously a yucky hack, but it works which is what counts at the end of the day right?