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!