views:

736

answers:

5

My webpage is suffering from two IE6 rendering bugs. Each of them have workarounds, but unfortunately said workarounds are incompatible with each other.

Here's a minimized test case. The behavior in Firefox/Safari is the desired/correct one. IE7 is unknown, since I don't have access to it right now.

First bug: #content has overflow: auto and contains a relatively-positioned div. IE6 incorrectly gives the relatively-positioned div a 'fixed' appearance. Workaround: Set position: relative on #content.

Second bug: The page sometimes shows a modal popup. The z-index on the popup and background are set really high to stop anything behind them from being interacted with. This works fine until I set position:relative on #content, which makes IE6 treat the z-index property completely wrong.

How can I make these bugs play nicely with each other? (Note: Remotely formatting the hard drives of users still running IE6 is not an option, much to my dismay.)

Edit: Here's a second test case that shows what happens when I apply position: relative to content. The first bug ('fixed' appearance of #content-header) is solved, but it causes the z-index bug to kick in and mess up the modal background.

A: 

While it may be the wrong solution, and probably way overkill, jQuery can do modal popups similar to this and works on IE6. I'll probably get downvoted for such a simple answer, but it is still worth considering, or at least looking at, other solutions before reinventing the wheel.

cdeszaq
Unfortunately, I'm stuck using an ASP.NET ModalPopupExtender, since the page has some server controls on it that need to be run. Being able to do everything in jQuery would make it so much easier! :(
Brant Bobby
+1  A: 

There are a myriad of implementation as to how to avoid the massive issues with ie6 (and below) conformity. The only one that has actually worked for me (to a great extent even) is Dean Edward's solution.

Try to insert the following line in your main header:

<!--[if lt IE 8]><script src="http://ie7-js.googlecode.com/svn/version/2.0(beta)/IE7.js" type="text/javascript"></script><![endif]-->

-- and see how it goes from there (and what you still need to handle, since it probably won't fix everything).

The script size is a mere 30kb, and will only be loaded in ie6 and ie7.

The google code url is (obviously) http://code.google.com/p/ie7-js/

Chrysaor
A: 

@Chryasor: IE7.js is indeed a useful script, but it doesn't address either of the layout bugs I'm tripping over.

Brant Bobby
A: 

Implement something like we've done at Ra-Ajax.org (hint, visit the site with IE ;)

Seriously, even prototype.js and 37signals have STOPPED supporting IE6 now, I think it's time to move on...

Thomas Hansen
It's out of my control. I'm creating an intranet app for an organization that is currently standardized on IE6 (due to the fact that they have OTHER intranet apps that don't work in anything but IE6). I do like what you've done there, but I'd sorta like to, you know, get paid for my work. =)
Brant Bobby
A: 

I don't think using a library is too bad of a penalty to minimize my time working around ridiculous IE bugs.

We ended up using the bgiframe jquery plugin (http://plugins.jquery.com/project/bgiframe). It implements the iframe "shield" technique in a library. I figure that making IE6 users have to have a bit more of a library download penalty (which isn't really all that much) so that I don't have to go crazy about IE6 bleedthru is worth it.

P.S. I think the web developers of the world should start a class action lawsuit to force Microsoft ether to offer the equivilant of firebug for IE6 and IE7, make sure all IE6 and IE7 instances are upgraded to standards, or remove all versions of IE6 and IE7 from all computers on the Internet, or bail-out all web developers with a payment of $1M each for their pain and suffering!

Robert J Berger