How To Attack An Internet Explorer (Win) Display Bug

By: John Gallant , Holly Bergevin ,

Page 1 of 2

Set for printing


It's a well-known fact that the Internet Explorer (Win) browser has a wide variety of display bugs. While it may seem satisfying to badmouth that browser, IE is by far the most popular browser on the web, so whining about its drawbacks is not going to help very much.

Sadly, many authors who desire to make the switch to table-less design begin with high hopes, only to have those hopes dashed by what is sometimes known as the "Explorer bug suite." Some of those bugs are not "bugs" at all, but rather misapplications of the W3C standards. Although a full understanding of how IE "gets it wrong" is a full-time job, it is possible to get by with a modicum of bug fixing tools, which is what this article is going to teach you. All ready? Let's go!

Clearing The Decks

Before any bug fixing can be done, it is necessary to make sure that the problem really is a bug, and not just improper coding, or a failure to understand how CSS positioning works. As a primer on bug hunting you should read Debugging CSS, the Easy Way, which details this preliminary phase in detail. It also describes how to create a "minimal test case," which can greatly simplify the issues to be addressed. But just making such a test case is time consuming, and job pressures often prevent people from going this route. Still, it is a highly recommended method to use, and one we put into practice regularly.

Even when a test case is made, it is not always easy to just look and say, "Aha! That's it!" While it's true that having extensive bug knowledge does help in locating a problem, many busy coders don't have time to devote to studying bugs at length.

However, once a minimal test case is prepared, there are usually very few page elements remaining to consider, and it becomes possible to fire "magic bullets" at various elements in an attempt to solve the problem. Be aware that these fixes are useless against any proper browser behaviors that are mistaken for bugs by CSS newcomers. It's up to you to have a firm grasp on the basics of CSS coding. You can read up on the subject in the following articles:

The fixes to be discussed are also worthless against any of the deliberate CSS specification violations that occur in IE/Win. To learn about the major non-bug IE misapplications, read:

One special problem worth pointing out is the way in which floats are "cleared," as described in the Float: The Theory article mentioned above. IE will usually (wrongly) allow a container to enclose a nested float, even when no clearing element is present. This creates the impression that the non-IE browsers are incorrect, when the real offender is IE/Win. Don't be fooled in this way as have so many others.

You may also find useful information on many smaller display problems in the Common Coding Problems series of articles here at CMX. (A search for the terms Common Coding Problems will get you a list of all the articles in the series.) Assuming these issues are well understood or are not relevant to your current problem, let's proceed to look at the bug fixing methods themselves, shall we?

{ position: relative }

This "magic bullet" was the first one discovered, back in December of 2001 by a certain author who's initials happen to be "BJ" (ahem). Anyway, the issue then was a technique developed by Eric Meyer here, which appears to "punch" a box out of the corner of another box.

Eric's method involves floating a box into the upper left corner of a text containing element, and then using 1px negative top and left margins, which has the effect of "pulling" the float up and to the left by 1px. This allows the float to cover, or obscure, the 1px borders on the larger containing box in that area. Then, the float gets a bottom and right border that seems to be a part of the overall border. Neat.

The problem with this method was that Explorer for Windows was failing to obscure the corner of the large element's border properly, ruining the intended "boxpunch" effect. It seems that IE/Win has a problem when an element is negatively margined out of the parent box surrounding it. The portion still within the parent "container" is visible, but any part that goes beyond the inner edge of the container's border just vanishes!

It turns out that applying a simple {position: relative;} to the negatively margined inner box causes the missing portions to magically reappear. Why? Well, moving right along... Seriously, no one knows why this happens, except perhaps the Microsoft engineers, and they aren't talking. Suffice to say it does work.

Soon, this fix was found to work on other IE bugs as well, specifically the Peekaboo Bug in IE6 (look on the third page of the article). We'll get back to the Peekaboo bug in just a little while.

Another primary use for this fix is occasioned when a floated image is in a container and either the container or the floated image has been made "relative." In that case, the floated image can and will "hide" behind any background that may be placed on the outer container element. Removing the relative positioning or making both elements relative will bring the floated image "up front," allowing it to be seen.

Problems With the "Relative" fix

Usually this fix will not adversely affect other browsers, but as just explained, in the case of floated images it may be necessary to perform a "double" fix, using {position: relative;} twice. Figuring out where to apply this fix is not usually a problem. Just stick it on one element at a time and check to see if the bug is zapped. In the event that this fix does cause trouble in other browsers, you may hide this fix from them, feeding it only to IE/Win via the methods outlined in the next section.

Page 1 of 2 1 2 Next

Download Support Files

Downloads are disabled during your trial period.

IE bugs, CSS bugs, bug, float bug, Peekaboo bug, Escaping floats bug, Internet Explorer, position relative, holly hack, tan hack, mac-hack, hacks, descendant combinator, child combinator, universal selector, Star HTML