This week at my Clark-Kent-day-job, I was working with JQuery, which is usually a pleasure. However, in this particular occasion, Microsoft, circa 2001, stepped in and defecated all over my happy times.

I had just finished coding a fancy overlay and dialog for our application (in a minimalistic set of JQuery code), when low-and-behold, during IE 6 testing (could it be anything else?) various parts of my application UI were, for lack of a better word, disappearing. When my beautiful dialog obtained focus, several key elements of the UI decided they didn’t want to render any more.

To make things a little more insidious, scrolling and re-sizing would (sometimes) cause the houdini-esque elements to re-appear, and then stay visible.

Now, my team had actually seen this previously with some form elements disappearing in IE 6 (Clayton, I’m speaking about you). We were able to circumvent the problem by adding some divs, taking other divs out, and basically just avoiding the problem. Unfortunately, this time the items disappearing were so far removed from the work I was actually doing that I wasn’t too keen on making a bunch of DOM changes in that stable UI just to keep IE from being asinine. So, I chose to research the problem, and I couldn’t believe how much information there actually was. Searching for ‘IE disappearing elements’ on Google is like picking up a rock with an entire Ant colony under it. At least I found the answer to my problem: enter the IE “Has Layout” property (link to a site dedicated to this issue). Here is a summary from the site describing what 'hasLayout' actually is:

MSIE has a quite dated rendering engine (not surprising, as IE is based on Mosaic). In old tabular times, almost any element (except inline content) was a box. There was no way for content to leak from containing table cell, or for table cell to leak out of table…

Many years have passed, and Microsoft began adapting archaic Trident engine to make use of CSS. However, CSS changes the fundamental assumption that old engine was based on - the one that “anything significant” is a rectangle that contains all its content. CSS allows content to overflow out of container. This may happen when content is floated, or if content is too tall/wide to fit inside constrained box.

[…]

Microsoft’s “genius” coders decided to fix their ancient engine in a rather bizarre way. And that is where the hasLayout “property” comes from. Every element has hasLayout set to either true or false. If it is set to true - element is a box that is responsible for rendering itself. Therefore, element would be expanded to contain overflowing content, such as floats or veryverylongwordswithoutanybreaks. If hasLayout is set to false - element does not render itself, and instead hopes that some ancestor with hasLayout set will do the job for it. This is where the majority of IE bugs come to life.

The hasLayout “property” is not a CSS property, you can not set it with {hasLayout: true;} it would be too easy. An element with hasLayout set to true is often referred to as having layout, and hasLayout of false is referred to as not having layout.

So, in other words, when you’re having magic disappearing elements, it may be related to rendering bugs in IE that are some-how associated to the ‘hasLayout’ property being incorrectly set. It is beneficial to spend some time digging through your DOM looking at the ‘hasLayout’ property can usually help you find the culprit. HasLayout.net provides some novel advice on doing so - simply run Javascript in the URL bar to alert the state of the loaded DOM (such as this example from their site):

javascript:alert(menu.currentStyle.hasLayout)

Thankfully, in my application we have an IE-6-specific CSS file that I could stuff my IE only CSS hacks into. Sure enough, I went to a few elements that were ‘hasLayout=false’, and gave them a property like this:

#someElement {
    zoom: 1;
}

… and my problems went away. Well… almost.

There was one other element that I couldn’t reliably fix in any capacity using CSS properties, so right now I have a hack of hacks in my Javascript for my dialog:

// Before the code that actually triggers the rendering bug.
$("#someOtherElement").hide().show();

By hiding and re-showing the element, IE seems to pay more careful attention to the rendering of that element before I trigger my re-rendering.

Yes, I still hate IE.