1 Posted by Claire on 8 February 2006

there is a small error in the demo, the #seconddiv which has a width applied is spelled wrongly in the actual HTML so the width is not being applied. The hasLayout is therefore false and correcting it fixes the hover problem.

Though this does mean that hasLayout is a requirement for this situation in IE7B2. It's not in IE6

2 Posted by Carl Camera on 8 February 2006

Thank you Clarie! I must have misspelled my div id in my original stylesheet -- and then transferred the error to my test page. I apologize to everyone for not testing this more before submitting it.

3 Posted by Claire on 8 February 2006

No problem Carl, as far as I can see it is still an IE7B2 rendering error because if that "hasLayout" is not set to true, (the width is doing that) the ul disappears as you describe, whereas it doesn't in IE6

I've seen a couple of reported "disappearing element" bugs which I presume are connected with this property - especially where background images are involved, all so far have been corrected by setting hasLayout to true.

4 Posted by Carl Camera on 8 February 2006

I'm not a has-layout expert so correct me if I'm wrong, but my understanding about has-layout is that the elements without "layout" have no width and therefore are not rendered.

On the test page, the list is hiding not disappearing. After hover, the list *is* there -- it has a width -- it just gets pushed behind the first div's background image. If I put a border around the UL it peeks out from under the masthead image. If the first div's background is removed, the ul shows through.

5 Posted by Bruno Fassino on 8 February 2006

Carl, you are correct, after the hover your list is hidden under the masthead background. I don't known if the bug is strictly related to hasLayout or not, it is anyway a bug. And there are probably variations. I've created a simplified test case where position:relative seem to fix the problem: http://www.brunildo.org/test/ie7b2_negvhover.html

6 Posted by Claire on 8 February 2006

Carl, your example shows that this "bug" does have a simple hasLayout only fix but that's because the construct is different than Brunos. (thanks Bruno for a different example, indeed for all your hard work! :))

I still think it is a hasLayout error, and am attempting poorly to make a simple comparison demo, will post link when ready

Carl, my take on hasLayout is that it is not as simple as width or no width which produces a symptom and then a fix, the whole construct to the build up of the symptom is key.

What the Ingo Chao article [http://www.satzansatz.de/cssd/onhavinglayout.html#rp] says about position: relative's involvement in this is very rightly wary of coming to a conclusion or providing a a-z guide (would be nice though ;)). But the advice in that article to not set position: relative without also setting haslayout=true is wise, and note they also say to check the whole construct.

Anyway, I think we agree this is still an error and there is no simple fix as it is condition dependant i.e. it wouldn't happen, or at least the symptoms would not be the same, if the hasLayout was not triggered in the first place, which it is in Brunos demo, but real life scenarios and simple demos do not mix very well, do they ,unfortunately

7 Posted by Carl Camera on 10 February 2006

To Bruno -- Thanks from me as well. Your test page is much better at showing this hover behavior. Would it be okay if I added a link from my test page to your test page?

8 Posted by Claire on 10 February 2006

some more random thoughts, the relationship between position relative and hasLayout plot thickens.

I haven't got a sample of my own but I came across: http://www.gtalbot.org/BrowserBugsSection/MSIE7Bugs/TransparentBackgroundColorBug.html which the author has billed as background transparent not being supported, however I think this is the same error we're discussing here? there is a negative top margin involved and setting either hasLayout or position: relative; on the affected elements brings the text back to the top. Bruno could it be the collapsing margins or stacking level adjustments part of hasLayout? ~ it seems the variations could be endless

PS: Bruno, I apologise for not crediting you for the above hasLayout article too..

9 Posted by Bruno Fassino on 10 February 2006

Claire, yes, that example looks like a variation of this same bug: when the box with negative margin has hasLayout=false it is always stacked behind the first one (no hover is necessary to trigger this wrong stacking.) I can't agree more with you that hasLayout has many effects on the stacking and so is intertwined with position:relative...
@Carl: Sure! (If you prefer, feel free to add to your nice page the simplified test case.)

10 Posted by Gérard Talbot on 22 March 2006

This bug is fixed with IE 7 beta 2 build 5335.5 (released on March 20th 2006).

The list elements appear with bottom borders when hovering over them.
Same result also with the first hover demo at
http://www.brunildo.org/test/ie7b2_negvhover.html