|What is haslayout in the IE Browser?|
What is haslayout? how to use it? please explain. Using this haslayout will solve ie6 bugs like double margin bug, extra space bug, 3px bug? I found that in ie developer tool when i use float to a div, i will get haslayout=-1. what does it mean? If i remove float to a div, nothing is displayed. please help!
Legacy IE versions have a fundamentally broken rendering engine when it comes to CSS. "hasLayout" is property in that engine one can trigger on an element. It's a common thing to try when faced with a number of the legacy IE bugs, but it's not a cure-all factor either (so applying it all over will not help you get rid of all problems). My favorite way to trigger hasLayout is to add "zoom:1;" to the CSS in the appropriate conditional comment.
if you really want to know you could start here [webmasterworld.com] (pre IE7) then there is an updated list of properties [webmasterworld.com] once IE7 came out.
The -1 that IE is showing you means hasLayout=true for that element, if it were showing 0 then hasLayout=false
It is not necessary to try and avoid it being true, in fact that's pretty near impossible, e.g. you can't just unfloat an element as that will not suit your layout or other browsers, so go with the flow when developing, use another browser for testing
Where it becomes troublesome. Sometimes in order to fix legacy bugs it's desirable to try to set it to true on elements that don't have it triggered and are you giving problems in IE. That's where you often see (another IE Only property)
zoom: 1; trick banded about as it's the easiest property to use which which does not affect any other browser
The double margin bug is not a hasLayout bug, but is easily fixed by adding
display: inline; to the affected float.
The 3px bug is actually a two part bug not so easily remedied with a blanket fix, in IE6 using hasLayout to fix the 3px Text Jog, then triggers IE's buggy float model and causes the 3px Float bug :o - though it can always be fixed a negative margin trick is usually required too, hence best to always keep IE fixes in a conditional sheet..
As usual I think the best thing is to develop in any other browser until satisfied then test in IE7 first! A lot of the "hasLayout" related bugs were fixed in IE7, and there may well not be any issues.. however they weren't really fixed, hasLayout is still in IE7, MS just targetted some of the more well known legacy bugs and patched accordingly so there might be some issue that you can't find an explanation for in which case there will be a fix still ;)
Then test in IE6 and if any of the well known bugs are triggered try zoom: 1 on the affected element and if it fixes it you're done.. put those zooms in an IE6 sheet and move on. Don't try to figure hasLayout, IE8 has apparently removed it completely and talk of IE6 support waning so hopefully this means this hasLayout 'thing' will all become a dim and distant memory ;)
[edited by: SuzyUK at 3:16 pm (utc) on June 16, 2009]
Thanks for that summary, SuzyUK. The essential tools I need to cope, all in a nice, compact presentation.
Thank you very much for your detailed anwser. But My targeted customers are form ie6. Exactly what is haslayout? If i have seperate tricks for legacy issues, then what is the use of haslayout? please explain...
|My targeted customers are form ie6. Exactly what is haslayout? |
harish, follow the first link in SuzyUK's answer - the one that says "you could start here (pre IE7". That should give you a start on more understanding.
Good on you for using the developer tool to look below the surface of your code. Much better to identify and deal with the exact cause of the trouble than to just apply more and more "fixes" until everything looks nice. Keep at it!
I agree with tedster re following the link, and as layout is a proprietary concept - specific to ms ie, there is a page dealing with it in the library: [msdn.microsoft.com...] Another explanation I find helpful is: [satzansatz.de...]
In terms of your question "what use is hasLayout" when you already have "tricks" for legacy issues, my thoughts would be to understand that hasLayout is not really a "trick" to fix legacy issues. Layout is a characteristic that an element either does or does not have.
As explained in the posts SuzyUk linked, some elements have hasLayout=true by default, some gain layout (haslayout) when certain css properties are applied to them. Whether an element has (or does not have) layout will affect the way it behaves, but there is no "layout" property, so it has to be indirectly "triggered" by setting a property that will cause an element to gain layout, or avoided by not applying properties that will trigger it on an element that does not have layout by default.
The value of layout is that it may explain why the element displays/behaves differently in ie than it does in other user agents. In addition, layout may be the cause of many display "bugs" previously thought to be separate and unrelated. As SuzyUk says, some of those have been fixed in ie6+, but you are coding for that browser. Knowing about layout may make it possible (although not always) to deal with multiple display differences by adjusting the layout rather than applying multiple "fixes". For example, as SuzyUk discusses, the common trick of deliberately triggering hasLayout by just setting zoom:1.
Hadn't noticed that SuzkUk's post was credited in the MS article before. Way to go WebmasterWorld!
[edited by: engine at 9:31 am (utc) on June 17, 2009]
[edit reason] fixed url [/edit]
What alt131 says, :)
|Hadn't noticed that SuzkUk's post was credited in the MS article before. Way to go WebmasterWorld! |
:) heh, Yes our 15 mins.. truth be told we, WebmasterWorld, Ingo, PIE were all "discovering" this together I think, perhaps even MS themselves!
|Exactly what is haslayout? |
Well that's really hard to explain as I'm not a browser engineer, but I'll try as long as you realise this is how I think about it my head.. technical peoples might be able to shed more correct terminology for me :)
It's something that has been in the Trident(IE) rendering engine since the beginning I think, it was MS's way to get elements to become responsible for drawing/containing their contents (like a block) in the old days. It's probably responsible for the fact that IE5.5 and below incorrectly supported width/height on inline elements, and also why block level elements wrongly stretched instead of overflowing.
As CSS uptake increased during the last 10 years MS 'tried' to make their browser compatible as well as trying to set standards of their own. They tried to work around/with their existing internal "drawing" mechanism, the mysterious hasLayout property.
However when IE6 was released in 2001 along with its numerous "CSS enhancements [msdn.microsoft.com]" it became apparent there was something really wrong! bugs were popping up everywhere and nothing was being done by MS to fix them. Because we landed up stuck with IE6 for nearly 6 years (the most important 6 years for CSS2.1 uptake!) with no updates or fixes, we had to learn to work around and with them! Bug Fix sites popped up and a few dedicated souls dug deeper into the problem, our own DrDoc started the ball rolling in 2004 [webmasterworld.com] with an interesting theory which eventually landed up leading us to the "hasLayout" property.. remember that there was nothing documented about this property before then, not even on the MS site!
but as best as anyone can figure..
The Box Model is the most integral part of CSS. Prior to IE6 IE used a different Box Model they included padding and border inside an elements "box". Margin also has a part to play in the Box Model too (hence problems with float clearance sometimes?).. Now, I assume this was nice and easy for their Layout rendering mechanism (hasLayout property) to cope with, but when they "enhanced" IE6 to use the correct (per CSS specs) Box Model the hasLayout mechanism ran into trouble, IE had to count :o
One of the simplest examples I've noticed as a common factor.
When an element with padding and border, but no width is responsible for containing another element the internal element doesn't have a clue what size to be, or it sometimes counts wrong, or can't figure out where to position other internal elements, that is the external element not being able to "take responsibility" for it's contents and then that's where weird things happen.
Quote from that previous linked post via IE5.5 specs
|Internally, having layout means that an element is responsible for drawing its own content. In future versions, it may be possible to have non-rectangular layout elements, but in Internet Explorer 5.5, having layout basically means an element is rectangular. If a layout element has contents, the layout of its contents is determined by its bounding rectangle. (You can actually cause any element to have layout simply by specifying a width or height on it, positioning it, or making it contentEditable.) |
Later discoveries told us that when this happened that is when we had to go in and force one of those elements to become responsible for its content. i.e. we had to trigger IE's hasLayout property to -1 (True) - We have no way to access the hasLayout property directly with CSS but we can trigger it to true when required using one of the following properties:
IE6 CSS property values which set hasLayout to true
* display :: inline-block
* height :: any numerical value/%
* float :: left or right
* position :: absolute
* width :: any numerical value/%
* writing-mode :: tb-rl
* zoom :: any numerical value/%
then for IE7, all of the above plus some more..
* min-height :: any numerical value/%
* max-height :: any numerical value/%
* min-width :: any numerical value/%
* max-width :: any numerical value/%
* overflow :: auto, hidden or scroll
* position :: absolute or fixed
You cannot "unset" hasLayout to false once one of the above properties have been used, but 99% of the time that is not necessary anyway, the only time I've found it necessary is when display: none/block toggle is being used with :hover effects. Then it is best to keep hasLayout triggering CSS properties off the element to be hovered on and put them on :hover pseudo element itself
Anyway that's the semi technical update. If you have to develop for IE6, you still should develop on a compliant browser FF, Safari, Chrome, first so you make sure your CSS is right/valid to start with, then if there are any IE6 display oddities once you test in IE6, it will simply be a case of finding the responsible element and finding a way to set hasLayout to true for it.. don't try to out think it as you go along because as you go along, quite often a later addition to code will fix the initial problem anyway. Just be aware that when/if it does happen there's loads of folks here who can help you find out how to narrow the source of the problem or you could just try a site search [google.co.uk]
I think I encountered a problem with images that just wouldn't render in IE6 a few years back that was traced back to the hasLayout bug.