Introduction
This article is a summary about hasLayout articles already publicly available.
Please refer to the sources section at the bottom of this page if you would like to do some in-depth studying.
back to topThis article is a summary about hasLayout articles already publicly available.
Please refer to the sources section at the bottom of this page if you would like to do some in-depth studying.
back to topMSIE has 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...
back to topMany 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 very_very_long_words_without_any_breaks. 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.
The following elements have "layout" by default.
<html>, <body>
<table>, <tr>, <th>, <td>
<iframe>, <embed> (non-standard element), <object>, <applet>
<img>
<hr>
<input>, <button>, <select>, <textarea>, <fieldset>, <legend>
<marquee> (don't ever use this one, non-standard and annoying)
This list might be incomplete. Many of these elements are not even mentioned in Microsoft's documentation. However, it is very easy to test whether or not an element has "layout" or not. For example, consider the following code:
skip the following code sample<div id="menu">
...
</div>To determine "hasLayout" value for that <div> we could run this code in the location bar:
javascript:alert(menu.currentStyle.hasLayout)After running the code above a message box should appear saying true or false which would represent the hasLayout value of the element with an ID attribute set to menu. If you get undefined it could mean that you specified a wrong ID, check your spelling.
back to topSetting hasLayout to true, or in other words giving layout, is relatively easy as opposed to setting it to false.
The following properties/values give an element layout:
position: absolute
float: left or right
display: inline-block
width: any value other than auto
height: any value other than auto
zoom: any value other than normal (see description below)
writing-mode: tb-rl (see description below)
As of IE version 7, few new properties give "layout":
overflow: hidden or scroll or auto
overflow-x: hidden or scroll or auto
overflow-y: hidden or scroll or auto
min-width: any value other than auto
max-width: any value other than auto
min-height: any value other than auto
max-height: any value other than auto
You may be not familiar with zoom and writing-mode properties. Both are Microsoft's proprietary extensions. They work only in IE and will not validate. Therefore, I strongly advise you to put those into condcoms. However, writing-mode property is already in the CSS3 Technical Report, zoom property may make it there one day, but to my current knowledge it hasn't yet.
Zoom obviously zooms an element. For example, zoom: 2 will render the element twice its size, whereas zoom: 1 will render the element with normal dimensions, and that is why I personally think this is the best property to use inside conditional comments for giving an element "layout" since it has no other effects on the element.
Writing-mode property is a proposed addition to CSS3 that determines how the text should be written. The tb-rl value stands for "top to bottom, right to left", a typography style used in East Asia. Western typography is depicted "left to right, top to bottom", which would be lr-tb value for writing-mode property.
Setting display: inline-block and then reverting it back to the original display property value inside another rule set does not remove layout, this trick can be used to give layout without the use of conditional comments when you cannot use other properties. Here is how this trick would look like:
div { display: inline-block; }
div { display: block; } /* two separate rule sets */Properties overflow-x and overflow-y have also made it into CSS3 Technical Report, thus still might not be well supported at the moment.
Setting proprietary contenteditable attribute also gives an element "layout".
<p contenteditable="true">so lame</p>You should never use this one for setting hasLayout, it is shown here only for informational purposes. Not only contenteditable is a proprietary MS attribute (thus it will not validate) but also allows the user to edit the content of the element, which in best case will confuse the user.
The hasLayout "property" is read-only, you cannot set it directly with JavaScript for example.
back to topAll sounds good until you come across a bug caused by hasLayout set to true. Since hasLayout is read-only, there is no way to set it to false other than not using properties/values that set it to true. Exception to this rule is display: inline-block, setting it to another value does not set hasLayout to false.
You cannot set hasLayout to false on elements that have "layout" by default. Luckly, most bugs in IE are caused by element not having layout.
back to topWith my experience I can say that around eighty percent of IE bugs are caused by an element not having "layout". Disappearing Content Bug is a perfect example of a layout bug.
Bugs that are caused by the element having layout are not that common to come around. One of them can be seen here:
This is not one line
In IE this text will be shown in one line. It seems that the cause of this bug is that the <p> with hasLayout set to true does not properly inherit the white-space property from the parent element. Setting white-space: pre on the <p> itself or making sure it does not have "layout" fixes the bug.
IE hasLayout bugs are often present themselves with the most bizarre issues. If IE does something that you are having problems to explain with words - the first thing to try would be to give an element "layout".
back to topMon Oct 8 22:24:41 2007
Hi, apologies and you'll probably want to veto this, but I thought you might like to know how I found your site. My google query was: 'what's with this fucking IE hasLayout issue?' Cheers guys, J
Mon Oct 8 22:23:07 2007
Thanks guys, Finally, I've found an explanation that makes sense. Although the question of 'how did IE come to be so?' still exists …
Sun Nov 25 16:17:57 2007
Hey thank you for the site Zoffix and all those involved. I have to say I'm pleased to see more focus on the deficiency of IE. Although I would love to follow the "to cool for IE" practice, like I'm sure many here would, it simply isn't viable as a freelance designer. A comment this site itself, is it possible to include the date of writing and/or last update in each page. As I'm sure you are aware, the world of browsers and their conformity to standards is rapidly changing, hopefully for the better.
Sun Nov 25 16:52:51 2007
Yeah, ok, I'll include the dates. So far the site was last updated in the start of October, 2007, with the exception of the text-align bug which was written later.
Mon Dec 3 07:41:22 2007
Very nice. Thank you very much! However; zoom changes the way IE (6 at least) are treating padding-top/-bottom for inline elements. After zoom :1; a span with padding-top: 8px; will be rendered as a block element pushing above elements 8px up.
Mon Dec 3 17:17:24 2007
It's not 'zoom' that changes it. It's the way inline-level elements with layout would behave. Although, that's pretty much the bug on which the unknown width block level centering ( http://www.zoffix.com/css/center#block-no-width ) is relied upon.
Mon Feb 18 02:35:31 2008
Thanks, that was very informative and helped me solve a fiddly layout issue.
Thu Apr 17 23:34:17 2008
This information was definitely very informative - gives me a look into what a lot of IE's bugs relate to. I've gone through every positioning and layout issue with IE and never knew until seeing this that it was related to the hasLayout issue. Disappearing content, overflowing, and everything else in between were bugs I wasn't able to beat. If not for this publication, I would have still been exhausting every possibility for a solution.
Tue Jun 17 07:16:35 2008
Thank you very very much - I could resolve an issue in IE because of this information that you have provided!
Fri Jun 27 16:57:25 2008
position: relative does fix many bugs but only ``absolute'' gives "layout".
Fri Jun 27 16:37:35 2008
Above you said, "The following properties/values give an element layout: * position: absolute" I have fixed many IE layout bugs with judicious use of position: relative, with no ill effects on FF. Are you saying any value to the position attribute triggers hasLayout, or just absolute?
Use what is right for you: "Browse Happy - Online. Worry Free. Switch today!"
Don't use it unless you understand it. Please take some time to read these articles: