Positioned Elements and OS Controls, Applets and Plug-ins

The bordered element on the right is a draggable positioned element. Grab it and move it over the SELECT form element below. What happens? Probably not the first time you've seen this behavior. The SELECT element shows through the draggable layer.

There are certain elements that "float above" HTML elements. It is not a "z-index" issue. There is no fix. In this article, we will demonstrate this problem, in full. Hopefully, it will give you a better understanding of what to avoid when developing DHTML pages.

The Problem

When HTML first introduced the use of forms, it called upon already-existing controls within the operating system to display form elements. A checkbox, a text input, a drop-down SELECT menu, or any other form element, was created by placing the operating system's built-in checkbox, text input, or menu in a web page. That is, although they are called through HTML, they are not created by HTML, as say, a heading or a paragraph is. The easiest way to prove this is to view form elements on different platforms. They always correspond to the platform standard, not to anything you have coded.

In addition to form elements, the same behavior is witnessed with Java applets, Active-X controls and plug-ins, all of which are external components placed in the HTML page.

This "floating" had not been an issue, however, until the advent of DHTML and the introduction of positioned elements. Authors now find that they cannot position their elements over certain other elements, without having holes "bored" into the positioned elements.

Previously on DHTML Lab

This problem was first mentioned in our first Drag and Drop column, where the draggable positioned elements could be dragged over a persistent INPUT button.

In our puzzle columns, the puzzle was controlled by form elements. Puzzle pieces passed over the elements did not hide them.

Recently, we have developed the popular hierarchical menu script. Many readers ("many" is a gross understatement) have written to complain that the menus were not hiding the java applet that co-existed on the page, or the form elements, or plug-ins.

There is nothing we can do, except develop our pages with this limitation in mind.

What the Big Guys Say

Netscape has documented this behavior since the first beta release of Coommunicator 4. (the italics are mine)

"Layers can contain form elements, applets, and plug-ins, which are known as windowed elements. These elements are special in that they float to the top of all other layers, even if their containing layer is obscured."

Netscape Docs

Developers of applets and plug-ins are well-aware of this behavior, but the casual HTML author is not. Netscape has made this information available in its DHTML documentation, targeted at, and available to all developers.

The choice of words leaves a lot to be desired, however. Most of us may not regard these elements as "special."

I have not found similar documentation from Microsoft, in generally available format, although it may exist.

This Article

In this article, we will demonstrate these "special" elements. It would be best if you could test the behavior in both browsers, although the differences will be mentioned.

We will look at positioned element behavior, when positioned over:

• Form Elements
• Built-in Browser Plug-ins
• Java Applets
• Third-Party Plug-ins

Again, there is no fix. This article exists only to save you the hassle of creating test pages, by demonstrating the problem in full.

First, a look at form elements.