Series: IE's HasLayout Part 2

"Where's the content??"

Probably the single biggest clue that you are dealing with hasLayout issues is content that appears and disappears or a portion of the UI that is out of place.

To debug if and where the problem is, you can begin by adding the following rule to your CSS:

* { zoom: 1; }

If the issue goes away, then you are more than likely dealing with a hasLayout issue. The next step would be to remove the above and systematically add the zoom: 1; to the suspected elements. Once you find the culprit, put the zoom declaration in a separate IE CSS file and use conditional comments to source in that file just for IE.

"Who are the suspects??"

An absolute positioned parent container (a div) shrink-wraps to its child content. This is the expected standard behavior and is the actual behavior for IE 6 & 7 and Firefox. But things change if the child element has layout applied:






Normally we are looking for cases where we actually need to apply hasLayout to correct a problem, but there are cases where the opposite may be true, as in the above example.

High on my list of "run-ins" is the next example. I often have need to position parent or ancestral containers relative in order to position child elements absolute within that container. Problems occur when you might have an ancestor positioned relative that has grandchild element inside a floated parent. I know this sounds odd when stated like this, but with CSS layout, I find it occurs quite often. Here is what it looks like in the "big 3":



Apply hasLayout to the outer container and here is what you have:



One residual effect as you can see is the outer parent container now forms a layout box around its content. This is inconsistent, of course, with the standard (as the internal floated element has not been cleared) but in most instances you would want to clear the floated elements, thus gaining the box around all of the content resulting in the same conditions.

And there you have it. A short series, but this should be enough to help you be on the watch for bugs related to this problem as you develop.

Series: IE's HasLayout Part 1

This has been one of the most confusing and mysterious challenges I have had to face. It is not a 'one size fits all' type of issue. Each time you create a unique interface, each time you come up with a neat way to solve a layout issue (design personnel are great for providing these!) this hasLayout creature seems to rear it's ugly head.

I develop strictly in Firefox and only after getting everything completed and validated in FF do I QA my work in IE (6 and 7). About eighty percent of the time I run into issues here. And I would say about sixty percent of those ultimately wind up related to hasLayout.

To begin this series, let's gain some background. There are two type of elements - (1) those that arrange and size their own contents (e.g. buttons and images) and (2) those that rely on a parent (or ancestor) element to do so (e.g. div's and p's).

Those elements that have layout are responsible for sizing and positioning themselves and possibly any children - they do not depend on ancestor elements. A short list of the most common elements that have layout by default are:

• body and html (in standards-compliant mode)
• table, tr, th, td
• img
• hr
• input, button, file, select, textarea, fieldset
• frameset, frame, iframe
• objects, applets, embed

But the focus of this series will deal with those elements that are without layout in our work that require layout to "behave".

In the next entry in this series, we will look at some of the hints you can look for when this is the source of problems in IE.

Visit Bullet Proof Pixels!

Welcome to Bullet Proof Pixels!

Our official go live date is June 1, 2009 but I could not resist starting to fill our blog with material.

What will you find on this blog? Well, almost anything related to User Interface development. Mostly it will focus on subjects that are sometimes difficult to grasp (like the open series on IE's HasLayout property) or exciting solutions I run into or discover in my daily routine as a UIE.

Thanks for visiting and thanks for contributing!

Visit Bullet Proof Pixels!