本为讲述了如何解决在IE6下动态创建的DIV等Element会被Select等Form控件覆盖的问题。
It was about 1 year ago that Coalesys released the first WebMenu 2.0 beta. At that time we began demonstrating a technique for overlaying windowed controls in Internet Explorer.
In case you don’t already know, windowed controls in IE will always cover DHTML layers. That means if you have a DIV that pops up or floats on the page and it intersects with a windowed control (such as the common SELECT box), the windowed control will obscure the DIV, no matter what zIndex you have set for each element. More information is available in this Microsoft KB article.
The initial solution adopted by most developers who cared about such things (including ourselves) was to dynamically hide windowed controls when it was necessary to display the DIV over them. Far from being a perfect solution, it was better than the alternative of doing nothing at all.
It did have one very frustrating aspect. People who evaluated WebMenu didn’t understand why their select boxes would disappear. And we are talking much more than just ASP.NET developers, as we produce WebMenu for ASP, as well as general web development. It seemed like every day we received a support question, “I found a bug in WebMenu. The select boxes are disappearing”. And although we did provide the ability to turn the feature off, nobody really bothered once they understood the nature of the issue.
Then, as luck would have it, a developer called who wanted to use our product for it’s broad set of features, but who absolutely needed to have the menu appear over some windowed objects. What was unique about his call was that he had the idea for a solution and shared it with us. While we didn’t use the full scope of his idea, we were able to take from it what we needed to cover windowed controls in IE 5.5. So, enough yacking. You probably surfed here to read about the solution. And here it is:
IFRAME
The IFRAME control has a unique nature in IE 5.5. It can exist in both the zIndex of windowed controls and the zIndex of regular HTML elements. Simply put, you can shim an IFRAME under your DIV. The IFRAME will block out the windowed control.
Set up your IFRAME:
The src attribute is set with a useless JavaScript statement so that the IFRAME does not try to load a page (which you won’t notice it doing, but it will be the cause for tripping the “Unsecured Items” message if you use it on a HTTPS page).
You can code your IFRAME as a static element on the page, or if you are going to be using more than one of them you may want to dynamically create them as required. The insertAdjacentHTML() method is good for that.
Now, all that is needed is to size the IFRAME according to the dimensions of your DIV, position it, place it one layer beneath the DIV in the zIndex order and make it “visible”. The IFRAME’s style object will allow you to do these tasks:
iframe.style.top
iframe.style.left
iframe.style.width
iframe.style.height
iframe.style.zIndex
iframe.style.display
What about transparency?
If the DIV has transparent areas, you’ll want those areas to punch through the IFRAME to the page background. There are two ways you can make an IFRAME transparent. The one that works for this situation is to set the style object’s filter property:
iframe.style.filter=’progid:DXImageTransform.Microsoft.Alpha(style=0,opacity=0)’;
This in effect makes the entire IFRAME transparent, but it will still block out the windowed controls. The other technique, which uses the IFRAME element’s ALLOWTRANSPARENCY attribute, actually pertains to making the interior page background of the IFRAME transparent, so that any content inside the IFRAME can have transparency. However, this mode changes the nature of the IFRAME and it no longer serves our purpose for blocking out windowed controls.
What about IE versions prior to 5.5?
The IFRAME’s unique nature surfaced only in IE 5.5. Prior to this, IFRAMEs where straight windowed controls themselves. That means they could get above other windowed controls, but no HTML element (like the DIV) could be seen above them. There is a solution, but it involves a lot of effort to get working. You can dynamically write the content of your DIV into the IFRAME itself, get it sized appropriately based on the dimensions of the original DIV, and then just move it around as your absolutely positioned element. There are a couple of caveats:
1. The IFRAME, like any frame, has it’s own JavaScript environment. If you want DHTML actions in the IFRAME to integrate with the JavaScript functions in your main page, you will have to bridge the gap between the two JavaScript environments.
2. Mouse events, such as OnMouseOut and OnMouseOver, can be called out of logical order when the mouse moves between frames in IE 4 and 5. This problem is compounded when you are using timers and need to precisely control their execution and cancellation via mouse events.
Our original WebMenu 2.0 beta used this technique successfully for IE 4 and 5, but in looking forward to adding new features to the product, we could see that this solution “over-worked the plumbing” to a great extent. The “shim” technique compatible only with IE 5.5 had zero architectural impact and was chosen for this reason. You can still hide windowed elements in earlier browsers as an acceptable solution.
posted on Monday, July 21, 2003 9:30 AM by jking