Why does Internet Explorer need the “hasLayout” flag?

Question

Like many developers working on web sites for Internet Explorer, I seem to come across a lot of bugs that are caused by the notorious hasLayout flag.

I understand what this flag does and how it works (for the most part). A good explanation I read the other day (although I can't find the source) is that hasLayout in IE essentially means "Make this element a rectangle."

It's obviously more complicated than that, but it's pretty well summed up with that (in my opinion).

What I don't understand is why the browser uses this flag. When looking for an answer, I found one that sounded logical:

Internet Explorer had to deal with very old legacy code from before CSS was really in full swing. As an architectural decision to make the browser easy to add CSS on to it, the hasLayout flag was used to trigger certain CSS properties so the page would be rendered correctly. This dates back to around the time of IE4.

This almost made sense to me, until I realized that Firefox (Netscape at the time) had to deal with the same problem. Netscape has been around for pretty much as long as Internet Explorer, however it doesn't need any internal hasLayout flag, or anything similar,as far as I know.

Seeing as how the hasLayout flag is the source of so many bugs in Internet Explorer, does anyone know why IE has this flag and other browsers don't need it?

This is something I'd like to know purely out of curiosity if anyone has any theories or happens to know the answer. I'd like to understand more about why (or why not) this flag is useful.

Answer 1

The Netscape renderer was completely re-written post-NS4. IE's "Trident" rendering engine got no such love. This made good business sense - IE continued to improve incrementally while NS was being re-written, and partially because of this (and partially because of its distribution arrangement...) managed to capture a huge share of the market...

But the end result is an old, crufty codebase which makes life hell for developers, who must consequently be painfully aware of what should be hidden implementation details.

Now, that last point is key: a browser's renderer is an abstraction, allowing you to create in a few lines of markup something that would take hundreds or thousands of lines of low-level rendering and event-handling code. And like all programming abstractions, it leaks a bit... This is true for IE, Netscape, Firefox, Opera, Webkit... And each browser has developers working feverishly to plug the leaks in the abstractions. Except, for five years, IE did not. Other leaks were plugged, but the rendering engine became more and more sieve-like.

Together, these to factors conspire to expose things like hasLayout.

Answer 2

It is very hard to know without being able to look at their source code.

The following links are the most informative I have found so far:

• On having layout — the concept of hasLayout in IE/Win
• /IE7/notes/

The first one quotes an outdated document which contains a very interesting sentence:

Internally, having layout means that an element is responsible for drawing its own content.

And the second one says:

The object model inside Explorer appears to be a hybrid of a document model and their traditional application model.

Putting both together, my guess is that elements with hasLayout are in fact windows in the Win32 API sense — that is, things CreateWindow deals with. The elements without hasLayout then do not have their own "window", but are drawn by their nearest hasLayout-having ancestor, using some sort of layout code (somewhat like Qt's layout classes). Since only the true "windows" have the layout code (which draws their layout-less descentants), they are the ones which "have layout", so hasLayout.

If that is the case, there would be two different code paths layout code (the one for hasLayout, which would have to position the "windows" so they can be drawn later using the normal window drawing system, and the one which draws the children of the hasLayout "window" by hand while drawing the "window"). Since all code has bugs (and anedoctal evidence says IE<=6 has more than the average), both code paths would have different bugs, explaining why adding or removing hasLayout (effectively switching to the other code path) changes the set of bugs affecting the element in question. Not only that, but since you have two code paths working in the same document, the iteraction of both code paths would be another rich source of subtle bugs.

Other browsers probably avoided the problem simply by using an architecture which does not have such a dual layout path.

If my guess is correct, I would say that if you used a tool to show all the child windows the browser is using, you would find out that every visible hasLayout element has one, while the layout-less elements do not have one.