Positioned Elements and OS Controls, Applets and Plug-ins

This article was originally written in September of 1998, close to four years ago. Since then many new versions of NS and IE have appeared on all platforms. Completely new browsers like Opera and Konqueror are steadily being adopted by many users.

Unfortunately, the problems originally discussed in this article still exist, although possibly not to the degree that they did back then. DHTML authoring has grown exponentially in this time, so a review and update of the problem seems warranted.

The Problem Illustrated

The bordered element above 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. The best behavior is in NS6.1+ where only the scrollbars show through. All browsers, however, have some problem with SELECT elements.

The Problem Stated

There are certain elements that "float above" HTML elements.

• This is not a "z-index" issue.

• There is no fix.

• There are authoring workarounds, but they are not in the scope of this article.

The Problem Demystified

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.

More recently, users of our popular HM script 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. A workaround was suggested in Column 36: evaluate_upon_tree_show evaluate_upon_tree_hide.

What the Big Guys Say

Netscape has documented this behavior since the first beta release of Communicator 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

Microsoft explains the behavior in this way:

"This element is a windowed control and does not support the z-index attribute or zIndex property."

MSDN SELECT Docs

"The property does not apply to windowed controls, such as select objects."

MSDN z-index Docs

"As of Microsoft® Internet Explorer 5.5, the iframe object is windowless and supports the zIndex property. In earlier versions of Internet Explorer, the iframe object is windowed and, like all windowed controls, ignores the zIndex property. If you maintain Web pages that were designed for earlier versions of Internet Explorer that do not support the zIndex property, you might want to redesign the pages, especially if the pages contain iframe objects that are stacked on top of windowed controls, such as select objects. You can use the visibility attribute to hide windowed controls that you want an iframe object to overlap. You can also position windowed controls so that iframe objects do not overlap them."

MSDN IFRAME Docs

This Article

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

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

• Form Elements
• Built-in Browser Plug-ins
• Java Applets
• Third-Party Plug-ins
• Active-X Controls / IFRAMEs

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.