Question:
Is there a way to place and/or move a layer over different frames? I have a menu-frame on the left and a main-frame on the right. Now I’m trying to have kind of a “drop-down” menu in the left frame, which isn’t restricted to the size of that frame.
Answer:
The short answer is that there isn’t any way to do it, within HTML. The problem that you run into is that when you render an HTML document into a browser window, you are essentially creating a surface to render things on. DHTML is great because you can move things around on that surface, but the surfaces themselves are fairly discrete entities. If you had a single frame and were trying to display a pop-up window, that would be simple–create a “floating” DIV with position:absolute as a style attribute (or use a LAYER in Netscape) .
However, frames introduce an ugly level of complexity. A frame is essentially an individual browser window that happens to be displayed in conjunction with other browser windows. To pull off this trick, you basically need to designate a portion of the frameset to hold each window. Therein lies the problem. Frames arose in the first place because people wanted to have multiple sets of content in a single document. To do this in a consistent, easy to use manner, Netscape (and later, Microsoft) broke up the containing window into a rectangular grid, which could be in turn subdivided into smaller grids.
Such a solution was easy to implement, but it left out the situation where you want to have a floating frame. The thinking at the time was that if you really wanted to have a floating frame, you could always open a separate window. Unfortunately, no one bothered to create an attribute that would turn off the title bar of the window, something that’s always rather puzzled me. Granted, a window without a title bar can’t be closed directly, and it may pose something of a security risk because an unbounded window can be made to look like a system dialog. Still, there are times where having such an ability would be useful.
Both Netscape and Microsoft have implemented floating layers (ILAYER and IFRAME respectively), but again, they are essentially bound to the frame in which they are called–they float with respect to this surface, but not to the browser as a whole.
So what can you do? Here are a few suggestions–none of them is perfect, but they will work:
1) You may want to design around the problem. I have a similar quandary on a project I’m currently working on (I’ve run into the same problem, to be honest). The simplest approach would be to place a DIV, IFRAME, or scriptlet (if you’re running Internet Explorer) so that it appears close to the boundary between the two interfaces. It’s an illusion, of course, but it will usually work. The trick then is to communicate between the elements. If your buttons are in “ButtonFrm” and the DIV or control for the menu is in “DisplayFrm” then you can communicate between them simply by setting up aliases. For example, you can get a reference to the menu object from the button frame as follows:
Likewise, you can make references to the button frame with top.ButtonFrm.
2) You can write or use an ActiveX control to do this. This solution is of course IE specific, but if you have that luxury you can even make use of a pre-existing menu that’s already bundled with Internet Explorer. I believe this control is called the IE Popup Menu control; it can be added like any ActiveX control. Unfortunately, it is no longer included in Internet Explorer 5.0, which I’m currently beta-testing, so I couldn’t tell you the GUID. An ActiveX control can generate a window that floats above the frames, although a caveat needs to be stated here. When you define an ActiveX control you are creating a region that belongs to the browser, in the same way that a table or div element belongs to the browser. However, the ActiveX control can launch another window, which belongs to the control but not to the browser. This introduces other problems, unfortunately, including trying to keep the menu window active above the browser object and figuring out a way to dismiss the menu if a user clicks outside of it. It’s possible, but like menu elements themselves, harder to deal with than you would think. If you do design an ActiveX control for this task, keep in mind that it will still need to create a distinct window–the ActiveX User Control that Visual Basic supports belongs to the specific browser page, as would a Shockwave movie or similar component.
3) You could redesign your pages so that they incorporate IFRAMES or ILAYERS in a single document. While this solution isn’t always feasible for pre-existing sites, it actually has a number of advantages for new sites. A document embedding multiple IFRAMES can retain state information that’s much more difficult to do with regular frames. Referencing items is easier, and you can layer IFRAMEs on top of one another (although you can’t layer a DIV on top of an IFRAME). Similarly, you can use external components such as Macromedia Flash or Director within a document supporting IFRAMES, which can similarly be layered; in addition, you can even layer HTML on top of some of these components.
4) If you are looking at a dynamic HTML solution, you can redesign your interface to use collapsing lists. This design can be more useful since menus have the disadvantage of not being obvious when disabled.
5) You can embed your Web page within a scriptlet and make use of the customizable menu there. Scriptlets have a disadvantage in that you can’t change the target URLs at run time–although there’s nothing that limits you from having a scriptlet reference a frameset, which in turn references disparate URLs. Granted, the document gets pretty deep at this point, and is limited to the Internet Explorer browser. For a discussion of scriptlets, I would strongly recommend Dino Esposito’s excellent book “Instant DHTML Scriptlets” by Wrox Press.
In other words, sometimes the best solution is to re-examine the initial requirements to see if they really work well with the technology. A menu should be easy to implement in theory, but the practical limitations of current browser technology make the task almost ridiculously complex in practice. Of course, that’s one of the reasons why Web developers make the money they do.
