The Great Layers Bug and Dead End Syndrome

In theory, layers are stackable objects, each able to appear over or under other layers. In this paradigm we can imagine the base page itself -- that which is plain HTML not contained within a layer -- as the bottommost object in the stack. Consequently, any visible layer will appear atop the base page. With relation to one another, one layer may appear atop another layer or behind another layer.

The previous screenshot of horror, though, seems to violate this theory. The form field is part of the base page, and yet it overlays the layer. You can see that other portions of the base page, such as the "inn feature" graphic, properly appears beneath the layer.

The fault, gentle reader, is not thy own. 'tis the browser!

This seems like a good time to casually mention that Navigator 4 and, to some extent, Internet Explorer 4 both suffer from an enormous, catastrophic, infuriating, project-destroying, we-claim-it-as-a-feature-but-it's-really-a-monstrous BUG. Specifically, all form fields on the page are rendered atop all page content, including layers. Sometimes this "bug" is not immediately obvious, and sometimes the page has to be resized or reloaded for the bug to bite, but when it bites the scars are brutal.

Unfortunately, most tutorials which deal with layers, even variations on pop-up and drop-down menus, fail to mention this quirky "feature" (bug!) and that the whole house of cards comes tumbling down should the page content beneath the menus contain any form fields. In this particular project for this client, there was no way to ensure that no form fields would occur where pop-up menus might appear. When this happens, and there is no feasible workaround despite hundreds of grams of caffeine and cold wet towels, we must face up to Dead End Syndrome, or DES. There is no "magic bullet" cure for DES, but rather a long and painful process of psychological recovery, only after which can the project be re conceived and hopefully implemented successfully using an alternative approach. Ideally, this should be completed within a few minutes so that one's hourly rate does not bottom out too severely.

A developer recovering from Dead End Syndrome will likely pass through six stages before any productive work can continue:

1. Denial: "This bug CAN'T exist!"
2. Anger: "What kind of stupid company would release this crappy browser!?"
3. Loss: "All those hours ... wasted."
4. Anger again: "Dammit all those hours wasted!"
5. Self-pity: "Why oh why am I a web developer? I should've followed my dream ... ballet!"
6. Acceptance: "Fine. Back to square one. Nothing can stop me!"

Filled with a new spirit of vigor and Pepsi, we must re conceive the problem at hand.

Thinking Outside the Box

One possibility, to avoid the form field problem altogether, was to scrap the notion of pop-up menus and consider an alternative. Another popular DHTML technique nowadays clones the expandable/collapsable list, made popular by Windows' built-in File Explorer interface. Perhaps the table-of-contents could expand and collapse to reveal the article index for each topic. An attractive notion, but for this client it runs aground for two reasons.

First, these dynamic lists require the page contents to dynamically regenerate as a portion of the page is pushed down or pulled up. Internet Explorer 4 easily handles such on-the-fly repagination quite easily but Netscape 4 does not, placing extra coding burden on us. This is further complicated by the fact that this client requires all of our code to reside within a cell of a table -- we can't start redesigning the overall architecture of the site. Second, the indices to appear under each topic contain article titles -- some of these titles are quite long and the width of the table of contents cell is rather narrow. This would likely lead to links which wrap multiple times, a most ugly occurrence.

Jettisoning that idea, then, we turn back to the notion of the pop-up menus ... what if, we wonder, the popped-up menu resided within its own tiny browser window? If this new window were stacked atop the main browser window we could sidestep the form field bug, since that bug only bites when stacking within the same window. Still, there are concerns ... we have limited programmatic control over an independent browser window -- how well could we reign it into behaving as a subordinate menu rather than a living breathing animal of its own accord?

Roughly, we outline our concerns regarding the "launch a new window" approach into the following issues, preferably at a favorite lunch buffet:

• Popping -- the effort of spawning a new window and loading its menu content at the moment the user passes the mouse over a topic area will not appear smooth. This alone would undermine the pop-up effect and usability of this interface. The solution will be to hybridize the layers approach and the spawned window approach. Rather than re-spawn a window for each pop-up, we'll spawn one menu window when the page loads and try to keep it hidden from view. Inside that window will be all the layers, hidden, for each topic menu. When the user passes over a topic on the main page, the appropriate layer will appear visible in the menu window and the menu window will then appear atop the main window.

• Sizing -- ideally, the menu window's size should closely match the number of entries in the index. This is troublesome for two reasons ... first, if the window is resized horizontally, Netscape takes a moment to redraw it, causing an jarring visual effect. Second, Netscape limits the dimensions of a spawned window to 100 pixels by 100 pixels, preventing our menu window from ever appearing smaller than this. Internet Explorer poses neither of these restrictions. Ultimately, the solution will become a compromise: the menu window always has the same width but its height changes relative to the height of its content, but no shorter than 100 pixels within Netscape. This works perfectly within Internet Explorer and only creates a minor aesthetic glitch in Netscape when the index for a topic is very short, causing extra space to pad out the bottom of the menu, as seen in the side-by-side below.

  Navigator 4's 100 pixel height restriction results in extra padding when the menu is short.	Internet Explorer 4 allows for spawning small windows, giving our short menu a better fit.

• User interference -- normally, the popped up menu would disappear when the user selects a link or moves the mouse off the window. Unfortunately, these spawned windows contain operating system gadgets such as the "X", or close window gadget. We lowly web developers cannot prevent this. Trouble is, what if the user goes and manually closes the menu window? It would no longer be hanging around to pop up when the user passes over another topic and would likely lead to horrible JavaScript errors and a lack of paycheck. The only solution here will be to prepare for the rogue user -- we'll have to test to see if the menu has been closed before attempting to pop it up, and if it has been maliciously closed, re-spawn it again.

• Another user interference concern relates to hiding this permanently open menu window when not popped-up. Turns out to be quite easy in Internet Explorer due to its lax sizing allowances -- simply resizing it to 0 by 0 causes it to be minimized by the operating system. Again, this is not possible in Netscape, where we must again fallback onto a compromise: when not popped up, place the menu window behind the main browser window. Unfortunately, not ideal, because if the user minimizes the main browser window they'll see the menu window sitting there on the desktop. Oh well -- Netscape won't allow us to move a spawned window offscreen.

Having just been traumatized by an earlier bout of DES, the above outline is considered carefully before risking another heartbreak The principles seem sound. The compromises are acceptable to the client. The time has come.

Hubris 101
DHTML Pop-Up Menus: A Parable of Triumph and Loss (Based on a True Story)
Building the Imperfect Beast: Part 1 (menus.js)