Sent by Alan Gresley on 5 March 2008 12:12
--===============0885623512==
Content-Type: TEXT/plain; CHARSET=US-ASCII
Sent by Gunlaug_Sørtun on 5 March 2008 04:04
> Scott Sauyet wrote:
>> http://scott.sauyet.com/issues/2008-03-04a/
>> In IE7, IE6, and IE5.5, all on XP, I'm seeing something bizarre.
>> When you hover onto or off of the top menu item, the text box and
>> button move down the page. They keep doing this; it's not a one-time
>> behavior. In IE7 they will go on indefinitely. In IE6 and IE5.5,
>> they eventually disappear when they fall off the real estate owned by
>> the menu.
>> Has anyone seen this behavior? Any suggestions for how to get rid of
>> it?
> Alternative solution (in case one is ever needed)...
> <http://www.gunlaug.no/tos/alien/scs/test_08_0305.html>
> ....based on the effect well-placed 'hasLayout' triggers have on elements
> in IE/win. Otherwise no changes from the original.
> It's perfectly stable in IE6/7, but I can't check in IE5/5.5.
>
> regards
> Georg
> --
> http://www.gunlaug.no
Georg, your solution is really interesting, you have given both the #main-menu ul and #main-menu li
hasLayout. This squashed the bug with the padding in-tacked. My solution is different where I have
swapped the padding for margins instead and only given #main-menu li hasLayout (later inclusion).
http://css-class.com/x/what.htm
For general details, by swapping the padding for margins I evoked the non-collapsing of default
margins bug in IE where IE contains those margins instead of collapsing them. Giving hasLayout to
the list items squashes this bug.
Scott, both Georg's solution and mine (untested in IE/Mac) still has box model problems in IE5/Win.
Are you wishing to support this browser?
Getting back the the original bug. Off-line testing confirms that only a form elements reacts with
the padding bug and hovering the first and second list items will send the form element in IE/Win
continuously down. It's like IE moves the form element downwards when the padding bug is triggered
but doesn't restore it correctly in place when the padding bug is un-triggered, thus each time the
trigger is activated the form element is moved one more step onwards on it's continuous journey to
the abyss.
I beginning to think more and more how IE is very magical :-)
Alan
http://css-class.com/
--===============0885623512==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
______________________________________________________________________
css-discuss [EMAIL-REMOVED]]
http://www.css-discuss.org/mailman/listinfo/css-d
List wiki/FAQ -- http://css-discuss.incutio.com/
List policies -- http://css-discuss.org/policies.html
Supported by evolt.org -- http://www.evolt.org/help_support_evolt/
--===============0885623512==--
