How To Attack An Internet Explorer (Win) Display Bug

By: John Gallant , Holly Bergevin ,

Page 2 of 2

Set for printing

Previous

Dimensional Bug Fixing

A very large percentage of IE/Win bugs are triggered by the lack of any stated dimensions on elements that contain nested floats. In other words, if you have a box without either a width or a height, and nest one or more floats inside, some very weird display bugs may declare themselves. Such bugs can happen without floats, but are far rarer than the float variety.

The Peekaboo Bug falls into this "dimensional bug" class, as does the Escaping Floats Bug. There's the Peekaboo Bug again! So this hard-shelled devil is vulnerable to both the "relative" fix and the dimensional fix! Very interesting. Such is the nature of IE bug "science."

This sort of dimension-related IE buggy-ness has been known for several years, but simply knowing wasn't good enough. Very often, it is undesirable to apply a dimension to the buggy box. Using a height is usually unacceptable, since having the height be the default value of auto allows the content in the box to determine that box's displayed vertical height. If you give the box a defined height, it may not match the height of the content, particularly if text is involved and the user changes the browser text sizing.

A width may sometimes be used, but often the page design calls for the problem box to be "liquid," so as to automatically widen or narrow in response to changes in window size. Yes, a percentage width can also do this, but what if the box is a center column and needs to have pixel sized side columns next to it? It is impossible to have a percentage width on a box and pixel sized margins on that same box, because no one can predict how rigid pixels may compare against fluid percentages.

Clearly, using width as a bug-fixing dimension is less than satisfactory. There seemed no clean way to accomplish the task at hand, and yet by a strange quirk of fate, the Explorer browser itself came to the rescue.

The Expanding Box Trick

CSS gurus have known for a long time that when IE/Win sees that a box has a stated dimension that is not large enough to enclose the content of that box, the browser will wrongly enlarge the width of the box to accommodate unbreakable lines, such as long URLs. IE/Win will also extend the height of a box so that its content does not overflow the bottom border of the box. Browsers that more closely follow the W3C specifications let the extra content protrude beyond the height or width controlled box.

The Holly Hack

Since IE/Win will misbehave in this manner, when a dimension is needed to fix a float bug, a very small height, such as {height: 1%}, can be applied to the float container, and IE/Win will just make the box taller anyway. Thus, a small height does not change the appearance of the box, but IE seems to think the box is now "dimensioned," and so our magic bullet strikes home. Scratch one bug.

Details of The Hack

Since other browsers don't have the bug, and more importantly, don't wrongly expand height-defined boxes, this bug-fixing height should be hidden from browsers other than IE/Win. It is not necessary to hide this fix from earlier versions of IE/Win, since even though they don't have the Peekaboo Bug, they do have other dimension based bugs, and they all do the expansion trick. However, IE5/Mac doesn't incorrectly expand boxes, so letting that browser see the small height is sure to damage its display. Thus, the height needs to be hidden from it, as well as the other, non-IE browsers.

The following code is an instance of the Holly hack. Primarily, the Holly hack consists of a set of hiding methods wrapped around that 1% height, which is the key to the hack. Remember, the whole idea is to let IE/Win and only IE/Win see that height and apply it to the buggy box.

/* Hides from IE5-mac \*/
* html .buggybox {height: 1%;}
/* End hide from IE5-mac */

Code Block 1

Two Hacks in One: The first line of code is a CSS comment with an "escape" (colored red) just before the comment closing tag. The presence of that escape character causes IE5/Mac to ignore the closing tag of the comment, and think that the comment is still active. Thus, it ignores everything until it sees what it thinks is a correct CSS comment closing tag. The last line of the hack is a normal CSS comment, and its closing tag is what lets IE5/Mac begin parsing code again. We generally refer to these two lines (the top and bottom in the above code box) as the "Mac-hack," but it is also referred to as a "comment-backslash hack."

The second, or middle line, has, in this example, three items separated by descendant combinators, which are the spaces you can see, and then the height property within curly brackets. First item is a universal selector or star, *, which selects any element, followed by html (both also in red), followed by the element suspected to have the bug. The above code selects an element with the class attribute of buggybox that is a descendant of an html element, (which will always be true), when html itself is a descendant of any element (*), and applies a {height: 1%} to that element, in this case, .buggybox.

It so happens that all IE browsers, both Win and Mac, recognize an invisible and mysterious wrapper element around <html>. The use of the universal selector preceding html, also known as the Tan Hack (or Star HTML Selector Bug), works in IE browsers and nowhere else. Thus, the reason for using the "Mac-hack" is to prevent IE5/Mac from seeing this height just as other browsers are, because it does not wrongly enlarge the box like IE/Win, but it does read the Tan hack.

Note that the element to be given the height need not be classed. Any valid selector may be inserted instead of .buggybox, and even entire strings using descendant combinators may be used there. What really matters is that * html must always precede whatever target element is to be fixed, and that the * and html have a space between them, followed by another space, and then the target element.

There are other methods that can be employed to both give IE/Win the height-fix it needs, and not give it to other browsers. One method is to set the small height in the regular selector for the element and then override that height with the auto value in a following selector that uses a child combinator, >, which IE/Win browsers do not recognize. This requires knowing the direct parent of the buggy box. It is not a good idea to use spaces around the child combinator, as this can cause bugs.

Another method is to use the Tan hack to hide the height from browsers other than IE, and then override that height for IE5/Mac only, using a modified Mac-version of the Tan hack, which again uses the child combinator to prevent IE/Win from reading the redefined value. The Mac-version also requires an escape character (a backslash, \) to be used in each property name included in a ruleset to prevent IE5/Win from reading the rules. In the Mac-modified version of the Tan hack, the child combinator replaces the descendant combinator normally used between the star and html. This is shown in red in the last line below. The escape (the backslash character, also in red) is used in the height property. Both of the alternate methods just described are shown in the following code block.

Child Combinator Override Method
.buggybox {height: 1%;}
#parentElement>.buggybox {height: auto;}

Mac-modified Tan Hack Method
* html .buggybox {height: 1%;} /* for IE/Win */
*>html .buggybox {he\ight: auto;} /* for IE5/Mac */

Code Block 2

Which method should you choose? Well, as with most everything CSS, it depends. Of the three options presented, the one we would be least likely to use is the Child Combinator Override Method. We prefer to have the original selector for an element contain the correct value for the properties defined within, and use a hack, or filter, as they are sometimes called, to provide alternate values for IE/Win. The other two methods can come down to a matter of preference.

Note: The Child Combinator Override Method is our name for the method described in Code Block 2 above. As far as we know, there is currently no commonly used name for this method, or the one using the Mac-modified version of the Tan hack. Also be aware that if a future version of IE/Win finally does support the child combinator, this hack may backfire by letting IE/Win see the "wrong" height value, depending on what changes actually occur in that browser.

Trick Shooting

While having a "minimal test case" to try these fixes on is the best way, it is sometimes possible for a CSS coder to skip that step and just apply them directly to parts of a big convoluted page in the hope of "getting lucky." This approach can be problematic for newbies however, because what may look like a bug is often actually correct behavior, or an IE/Win specification violation. A good rule of thumb is to compare the display of a suspected IE/Win bug to the display in Opera 7 and a Mozilla based browser. If both these non-IE browsers look good then it's a fair bet you are seeing an IE bug or misbehavior. Telling these apart is another matter, requiring knowledge of the IE Float model, the IE Box model, the IE 3px problem, and occasionally other issues as well.

These two "magic bullets" can work wonders, enabling authors to utilize many layouts previously out of reach due to IE bugs. They are by no means cure-alls, though they may seem as such at times, and they are certainly no substitute for good coding practices. While there are other fixes not detailed here, the ones we have described are the primary weapons in use today for zapping bugs in complex table-less designs. One recent and very tricky float layout employs as many as eight Holly hacks to force compliance from "that" browser. Bang! Bang!

 

Page 2 of 2 Previous 1 2


download
Download Support Files


Downloads are disabled during your trial period.


Keywords
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