PDA

Click to See Complete Forum and Search --> : Finally, why Internet Explorer and Lists Don't Get Along

toicontien
10-12-2006, 01:35 PM
I've pulled my hair out time and time again when trying to get OL and UL lists to display correctly in Internet Explorer. No matter what I do -- set widths, positioning, the zoom property -- sometimes lists and list items NEVER appear correct. I think I've found out why.

I started poking around the Document Object Model in IE using the DOM Viewer (wish I could remember the link to download it). I discovered that OL, UL, and LI elements cannot have the hasLayout DOM property set to true. If hasLayout is set, it's ALWAYS false. Lists and list items never have layout, and thus things like the Tantek Hack, and zoom do not fix many problems when the solution is to invoke hasLayout.

I've even tried absolute positioning, and setting the zoom property using JavaScript. Still, IE-Win would not set the hasLayout DOM property to true.

So if you ever run into a display bug with lists in Internet Explorer, this is probably the reason why. Thoughts?
Kravvitz
10-12-2006, 03:19 PM
That's not what I've observed. Perhaps you thought that -1 means false? is hasLayout is set to -1 it means true.

Are you referring to the DOM Explorer in Beta 2 of the IE Developer Toolbar (http://blogs.msdn.com/ie/archive/2006/02/08/527970.aspx)?

This explains a fix for a common IE bug:
White space bug revisited--the definitive fix (http://www.csscreator.com/node/6745)
toicontien
10-12-2006, 03:32 PM
I'm using the Microsoft Internet Explorer Developer Toolbar (1.00.1517.0). I'm not sure if it's the same one as you liked to. I downloaded it and installed it and it shows the same version number. I created a test page and the results were still the same. I was able to trip haslayout, but it was always set to -1. Here's the test code I used:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

<html>
<head>
<title>Testing hasLayout on lists</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" media="screen">
<!--
li, ol {
zoom: 1;
}
-->
</style>
</head>
<body>
<ol>
<li>List item</li>
</ol>
</body>
</html>


Try it for yourself in the DOM viewer. In my version of IE, hasLayout is set for both the OL and LI tag, but its value is -1.

IE: 6.0.2900.2180 SP2

I do know how to fix the white space problem, I'm just wondering if this strange behavior with hasLayout and the whitespace problem are related.
Kravvitz
10-12-2006, 04:30 PM
I created a test page and the results were still the same. I was able to trip haslayout, but it was always set to -1.
Try it for yourself in the DOM viewer. In my version of IE, hasLayout is set for both the OL and LI tag, but its value is -1.
I have tried it myself. hasLayout is either 0 or -1. It never has any other value. I don't know why it's not a normal boolean.

I do know how to fix the white space problem, I'm just wondering if this strange behavior with hasLayout and the whitespace problem are related.
Many box model things, including this, seem to be related to hasLayout
toicontien
10-12-2006, 04:36 PM
I was doing some more poking around and yeah. 0 or -1. I seriously thought it was always 0 or 1 :) so now I feel like a moron.

Why Internet Explorer, WHY!!!? I know box model bugs are related to hasLayout. I just thought I found a quirk with that property's value. Turns out I didn't. So that's cool.

I need a break from work.
Kravvitz
10-12-2006, 04:43 PM
We all act like morons once in a while. It's part of being a programmer. ;)
toicontien
10-12-2006, 04:51 PM
I never act like a moron. I are a college graduate. :D
WebJoel
10-12-2006, 07:57 PM
Not related probably to thread as started, but IE's handling of UL and OL & LI is troublesome indeed. Esp. when you use an image for the hyperlink where it becomes quite noticeable, -you often get this annoying little 'white corner' to the lower-right of the image when you click-and-hold the link...
What triggers this can be 'white space' in the code itself, Below: this will cause the white-space bug in IE and the "list items" will be spaced as if there were two line-breaks(<br>) after each <li>:
<ul>
<li><a href="#">Link</a>
<li><a href="#">Link</a>
<li><a href="#">Link</a>
</li>
</ul>
Whereas this:
<ul><li><a href="#">Link</a><li><a href="#">Link</a><li><a href="#">Link</a></li></ul> Will not. But the above looks like crap and is a pain to edit, esp. if you have a long list!

Ways to thwart the IE white-space in UL/LI issue, include things like:
<ul>
<li><a href="#">Link</a><!--
--><li><a href="#">Link</a><!--
--><li><a href="#">Link</a><!--
--></li>
</ul>
Which is visually, to the human editor, a bit easier on the eye. It gets you around that 'virtual linefeed' that the [RETURN] has created.

Another way the white-space bug in UL/LI is defeated is to declare a bottom-border for the <li>. Even a pixel ( ul li {border-bottom:1px solid white;} ) is enough apparently to give 'layout' (if that is the correct parlance).

Certain rules if given to the the <ul> will prevent whitespace error occuring, among them are height:n, float: (L or R), position:absolute (out of document flow anyway), width: n, and zoom:n.

a {display: inline-block;}
a {display: block;}
is probably the easiest way to stop this white-space error. The "inline-block" triggers or gives "hasLayout" and the second "block" gets the link the way you want it without removing haslayout. Any anchor inside of any <li> picks up on this. Make sure "block" is second after "inline-block;" though. grr..

I hate IE. :o
toicontien
10-13-2006, 11:09 AM
And here's a real kick in the Twig and Giggle Berries: IE7 often shows gaps in lists regardless of whether or not use remove the whitespace nodes! No joke. The above fixes pretty much don't work in IE7. You've got to float the LI tags. That's the only way I've gotten the gaps to disappear sometimes.