| home / experts / dhtml / diner / seethru |
|
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 IllustratedThe 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 StatedThere are certain elements that "float above" HTML elements.
The Problem DemystifiedWhen 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 LabThis 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 SayNetscape 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." Microsoft explains the behavior in this way:
"This element is a windowed control and does not support the z-index attribute or zIndex property." "The property does not apply to windowed controls, such as select objects." "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." This ArticleIn 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:
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. | |||||||||||
Produced by Peter Belesis and
| ||||||||||||||||||||
All Rights Reserved. Legal Notices.
Created: Sept 20, 1998
Revised: August 25, 2003
URL: http://www.webreference.com/dhtml/diner/seethru/