SuzyUK - 2:49 pm on Jul 19, 2005 (gmt 0) What came out of that discussion led us to Microsoft's site and their proprietary hasLayout property [msdn.microsoft.com] and it seemed pretty conclusive at the end of that thread that, yes, whatever this property actually is, it is indeed the cause of 99% of the more common IE rendering bugs/errors (disappearing, shifting elements). But what is hasLayout With IE's new release coming up it could become important to know this property, they could e.g. base any "new improved" CSS support on modifying this property somehow, which could mean we need to understand it order to support backwards compatibility or even learn how it works/causes effects so we can fix the next set of problems, who knows. The first time we spoke about this, a year ago, I said: ".. haslayout and zoom.. I think they will be one of those never to be forgotten things.." I haven't forgotten ;) From Microsoft's own site the hasLayout property is Boolean Unsubstantiated Note though see example below
A year ago DrDoc proposed an interesting theory [webmasterworld.com], and asked:
"Is it true that IE has all these bugs (more seem to pop up every day), or are they all simply variations on the same theme? Maybe there's simply just one or two bugs, not tens or hundreds
Well a year later, that is still the question I would likely clearly answered!
There is now finally some interesting discussions starting to appear out there. So I would like to summarize bits I've collected in my own research and some bits from the little that's been written so far and would welcome additional thoughts and ideas.
Retrieves a value that indicates whether the object has layout.
it receives one of the following values.
true : Object has layout
What came out of that discussion led us to Microsoft's site and their proprietary hasLayout property [msdn.microsoft.com] and it seemed pretty conclusive at the end of that thread that, yes, whatever this property actually is, it is indeed the cause of 99% of the more common IE rendering bugs/errors (disappearing, shifting elements).
But what is hasLayout
With IE's new release coming up it could become important to know this property, they could e.g. base any "new improved" CSS support on modifying this property somehow, which could mean we need to understand it order to support backwards compatibility or even learn how it works/causes effects so we can fix the next set of problems, who knows. The first time we spoke about this, a year ago, I said: ".. haslayout and zoom.. I think they will be one of those never to be forgotten things.." I haven't forgotten ;)
From Microsoft's own sitehasLayout Property:
the hasLayout property is Boolean
Unsubstantiated Note though see example below***: this property is set to False by default, and once it is set to true, either by element type* or a specific CSS property**, it cannot be "reset" to false **CSS property values which set hasLayout to true
Note: zoom [msdn.microsoft.com] is a microsoft properietary property so will not validate, but it can be useful as a debug tool and can be used to help IE5.5+ if validation is not an issue. See this thread [webmasterworld.com] for some more on zoom.*Elements which have hasLayout set to true by default
Here there is some differing lists (even on MS's own site!)
Microsoft list the following elements as always having layout on the page regarding hasLayout:
but in the course of travels around their site I find there are more:
Dean Edwards also comments on another blog and in difference to what Microsoft says:
Whereas Microsoft says:
Now I don't know who's right having not tested that one, but I'll leave it in as an instance of why it's so hard to reliably document this whole layout thing ;)
What does hasLayout actually mean?
The terminology is slightly confusing perhaps, usually when we (CSS'ers) are speaking about layout we are talking about a whole page! But what this property actually does is determine (to the IE rendering Engine) whether a singular element is having or has layout. Then it detects a layout element as one deemed to have layout by default or that it is so because it gained it the setting of one of the CSS property values above.
OK, so why does that affect our CSS displays so much?
The way the CSS displays (or the visual formatting model) has been "tacked" onto IE's aging rendering engine and they had to make it fit ;) ~ (OT: worrying thought time: could it now be, with the impending IE7 beta release, that they're only going to do more of the same?)
The hasLayout property was only introduced in IE5.5, before that IE classified some CSS properties as "layout properties" [msdn.microsoft.com], they still do actually but, these properties are not the same thing as properties which set hasLayout to true
Previously in IE4 most every element was deemed to have layout, with the exception being inline elements in their simplest form, i.e. not absolutely positoned and not given a width or height (remember you used to be able to dimension inline elements, only IE6 CSS enhancements [msdn.microsoft.com] correctly stopped that behaviour introducing display: inline-block as the alternative.)
These simple non-laid out elements were then the ones which would not support IE's own layout properties (specifically, margin, padding and border), which I presume is where the original term came from.
reference table [msdn.microsoft.com]
Moving forward to IE5.5.. and from their page: The MSHTML Editing Platform in Internet Explorer 5.5 [msdn.microsoft.com]
Note: My Bold.
So if I read that right:
"Having Layout basically means an element is rectangular" and that rectangle is "responsible for drawing it's own content" and the "layout of its contents is determined by it's bounding rectangle".
If so that suggests the paradox that is "auto-enclosing" behaviour. Where those rectangles will stretch to contain their content even incorrectly e.g. floats and veryveryverylongwordsandlinks?
Is it also conceivable that this is why they can't implement min-width and max-width
Also if then an internal element does not have layout which parent element takes responsibility for the rendering/drawing of content? Again I would suggest that this has not been clarified to the rendering engine which is why we then have:
disappearing content, where no parent element takes responsibility
shifting content: there's a struggle as to who takes responsibility and repainting errors occur especially after a background change on hover?
display: inline-block [w3.org]
Is an interesting property, and one which I think has again being used by IE because it suited their purpose. You'll remeber that this is one of the properties that sets haslayout to true.
In the IE6 CSS enhancements [msdn.microsoft.com] we are informed:
This is just them tidying up the violation that inline elements cannot accept a width or height, but in return they are offering limited support of a CSS2.1 property (or are they)
According to the Definition of display: inline-block; [w3.org] this property should apply to all elements.
When you try to use inline-block on a block level element in IE it doesn't appear to work, but I quite by accident found a way it could [webmasterworld.com]. Now I think that the solution is no more than using the hasLayout property against IE!*** The solution involves two lines of code:
the first rule on it's own will not make 2 x divs sit side by side like it should, it will give the divs the required width and color, but it does not reflow them inline like it should.
adding the second line of code makes it work, although at first glance then the second rule's display property should overrule the first by order of the cascade and therefore according to specs we shouldn't be able to set height or width.
However back to:
That's what I think is happening, the first rule sets the hasLayout property to true, and even though the second one should reset it, it can't!
So I wonder how many other little anomalies we could workaround with CSS, if we ever get to grips with this.. lol then of course IE7 could change all this anyways, who knows
Absolutely none ;) except It seems clear that this "property" is the cause of a lot of IE's rendering difficulties and possibly that by continually trying to hack their own property in an attempt to make it fit they are causing even more paradoxes and it's likely not only us CSS'ers that will suffer.
There is likely still a lot to this little documented gem. hasLayout may never be fully understood, but for now I'm glad I'm aware of it and would welcome any further thoughts and information. just remember no personal site links please!
[update]: Microsoft on hasLayout [msdn.microsoft.com] ~ their own explanation[/url]
[edited by: SuzyUK at 7:52 am (utc) on Oct. 18, 2005]