Tuesday, August 14th, 2007

Work around the z-index issue with heavyweight IE components

Category: HTML, JavaScript, Library

Brandon Aaron has developed a general work around for the common, nagging problem with IE6 and heavyweight components such as a select drop down ignoring z-index.

Brandon created the background iframe (bgiframe) jQuery plugin which “provides a very small, quick and easy way to fix that problem so you don’t have to worry about it. No matter the size, borders or position the bgiframe plugin can fix it.”

In the simple case, you can grab a collection and call bgiframe on it: $('.fix-z-index').bgiframe();. You can also pass in data to mess with the top, left, width, height, opacity, and src parameters.

How does it work?

The bgiframe plugin works by prepending an iframe to the element. The iframe is given a class of bgiframe and positioned below all the other children of the element. In the default configuration it automatically adjusts to the width and height of the element (including the borders) and the opacity is set to 0. The element needs to have position (relative or absolute) and should have a background (color or image).

Check out the test page to see the plugin in action.

Posted by Dion Almaer at 8:18 am
27 Comments

++---
2.5 rating from 187 votes

27 Comments »

Comments feed TrackBack URI

Does this solution handle rounded corners?

Comment by Cameronw — August 14, 2007

@Cameronw: I’d say yes, as the opacity is set to 0 (zero) you wouldn’t see anything underneith your rounded corners element.

Comment by Marcel — August 14, 2007

oh, he reinvented the wheel

Comment by anonymous — August 14, 2007

Most designers know they can use the iframe wedge, but having it a one-line implementation is nice.

Comment by Jon Hartmann — August 14, 2007

You can find the docs for the plugin here: http://brandonaaron.net/docs/bgiframe/

Comment by Brandon Aaron — August 14, 2007

“src : ‘javascript:false;'”

IIRC you’re going to have issues with that and IE7.

Check out

http://jqueryjs.googlecode.com/svn/trunk/plugins/blockUI/jquery.blockUI.js

To see how they got round the issue.

Comment by JP — August 14, 2007

@JP: The hack is only applied in IE6 because IE7 fixes this particular issue.

Comment by Brandon Aaron — August 14, 2007

Take back my IE7 comment, as this is clearly only needed for IE6, dowp, need more coffee. ;)

It does seem that this plugin will only work with items that are contained with a block level element, that fill the entire size of that elements.

So if you have a div inside a p tag and the div is absolutely positioned to float above it you can’t use this plugin to give it a background iframe.

I always liked the way they did this in Dojo, that the iframe and the node you want to screen can be unrelated in the DOM the iframe is just sized and slid under the node, seems to give much greater flexibility.

Comment by JP — August 14, 2007

Great and so simple, thanks!

Comment by Riddle — August 14, 2007

@JP: Hmm … It looks like Dojo injects their background iframe into the parent element, same as bgiframe. http://trac.dojotoolkit.org/browser/dijit/trunk/_base/popup.js#L221

Also, why are you putting a div inside a p tag? That is invalid HTML.

Comment by Brandon Aaron — August 14, 2007

Good work, but I wanted to throw out an idea to the js framework community. Why not deal with the dropdown/absolute div problem by attacking the dropdown instead of the absolute div? I realize just about framework out there has dealt with the problem by “fixing” absolute divs with iframes, but what if we left absolute divs alone, and “fixed” the drop down component, i.e. built a custom drop down component with DHTML that doesn’t show up in front of absolute divs? In order to maintain graceful degradation, one could scan a page for selects in IE6 and change them to a DHTML dropdown. You could probably use the same code across multiple frameworks even. Maybe I will do this sometime, but just wanted to throw this out and see what you think, see if anyone is interested in such an idea.
I am not a big fan of the iframe hack, it is can be a big performance hit, and I have seen some stabillity issues with it as well (maybe they have been resolved). Even though I don’t enjoy the hack, good work with the implementation of it Brandon, I know it is not trivial.

Comment by Kris Zyp — August 14, 2007

@Kris: Thanks for the kind words. There are several combo box implementations out there already. For example Ext provides a really nice combo box to replace the native select form control.

Go to: http://extjs.com/deploy/ext/docs/
and the click on Form and ComboBox in the left side bar.

Comment by Brandon Aaron — August 14, 2007

@Kris
An iframe is a much more simple solution as it only requires a single element and a couple lines of CSS vs a fairly complex JavaScript widget. Also, you would no longer have the benefit of native OS controls.

Comment by Andy Kant — August 14, 2007

Always putting an iframe behind every absolute layer is bounded with some actions like resizing and positioning. This could be a performance killer in some webs and actions like a mouseover for example. Surely a matter of layout. But it’s also a nice way to ignore some unwanted dropdowns, if it’s only a “window” layer doing nothing more than laying over some content. A flash application layer for example.

Comment by Christoph B — August 14, 2007

In related news: Firefox 3 will have the Mac/Firefox scroll bar bleed through bug fixed. https://bugzilla.mozilla.org/show_bug.cgi?id=187435

Comment by Peter Michaux — August 14, 2007

will the iframe have unwanted side effects to BackButton-Fixes like StateManager
http://exanimo.com/javascript/using-the-statemanager-in-ajax-apps/
?

Comment by Jan Mentzel — August 14, 2007

@Jan Mentzel: Not it will not affect the usage of the back button or the back button fixes.

Comment by Brandon Aaron — August 14, 2007

“Also, why are you putting a div inside a p tag? That is invalid HTML.”

Just because it’s invalid doesn’t mean it’ll happen (there are occasions where people have write JS for the HTML they are given), how about an img tag inside a p that has display:block, position absolute (I see that often).

The Dojo code you link to is the 0.9 version, I was referring to the code in 0.4.3 at:

http://trac.dojotoolkit.org/browser/tags/release-0.4.3/src/html/iframe.js

It was only a suggestion, to help make the plugin more flexible :-)

Comment by JP — August 14, 2007

@JP: Maybe I’m missing something but that is still appending the Iframe to the node just as the bgiframe does. http://trac.dojotoolkit.org/browser/tags/release-0.4.3/src/html/iframe.js#L41
The case where you talk about a div inside a p tag, the bgiframe will work for that div or for the p tag. However, the p tag with an image inside is a different story. The image would need to be wrapped with another element for the bgiframe to work. Thanks for the feedback and the idea of just positioning the iframe under the element is an interesting approach.

Comment by Brandon Aaron — August 14, 2007

http://erainfo.blogspot.com/2004/09/mostrar-um-div-sobre-um-select.html

Looks the date.

Comment by Marcelo Martins — August 14, 2007

this is old plugin, and old news.
why post about it now?

Comment by vsync — August 14, 2007

It’s too bad this doesn’t include further info for IE7 – as there STILL exists issues with ActiveX objects (yes, unfortunately). Relative positioning is problematic, as is the click to activate issue. All together, IE7 still bonks depending on configs.

Comment by NICCAI — August 14, 2007

Done better here:
http://www.hedgerwow.com/360/bugs/activex-listbox/demo.php
and Here:
http://www.hedgerwow.com/360/bugs/css-select-free.html

Comment by hedgerFan — August 14, 2007

I really think it’s high time Microsoft fixed this problem.

IE7 be damned, IE6 is still one third of the market and therefore a massive thorn in everyone’s side. MS have bazillons of dollars, the fix is already written, they will just stubbornly not apply it to IE6.

Microsft you evil mongrels, FIXIE6!

Comment by pd — August 15, 2007

That and li:hover

Comment by Mike Ritchie — August 15, 2007

see also IframeShim for Mootools: http://clientside.cnet.com/wiki/cnet-libraries/01-browser-fixes#iframeshim.js

Note that this practice is not new:

http://www.macridesweb.com/oltest/IframeShim.html (2003)

Comment by Aaron Newton — August 15, 2007

Very useful plugin. It fixed a lot of my code for IE just in moment.

However, to make it more friendly for me, I’ve added a no-scroll behavior too in the plugin code:

iframe … scrolling=”no”class=”bgiframe”frameborder=”0″…

Thank for the useful tool!

Comment by rost — April 14, 2008

Leave a comment

You must be logged in to post a comment.