问题
Excerpt of the question: I have a menu which works in every browser but was buggy on IE7. I solved throwing zoom:1 but normally the hasLayout related problems involves float, position and stuff. Why this time zoom made it work?
I have a menu which works in every browser (even on IE8+) which looks like this:
Consists of a LI which holds a DIV working as a 1px border using a .png BG and a block A that have an icon and text.
The resumed HTML would be ul.adminMenu>li>(div.menuBorder)+(a{link}):
<ul class="adminMenu">
<li>
<div class="menuBorder"></div>
<a href="">link</a>
</li>
(...other li's...)
</ul>
The li.active gets a darker BG.
Unfortunately I'm obligated to make it work on IE7 Standards Mode (That explains why I use a div with .png instead of RGBA border) which is looking like this:
Yes. There is a whatsoever space between the start of li and the "border" div. I already tried the following methods:
- display:inline-block then block
- remove tabs and white spaces on the html
- font-size and line-height 0 on separator
None of them have worked and there is nothing on Dev Tools which points to a margin or border (all are 0 with !important).
So the question is:
There are no floated elements, no absolute positioned things, just blocks. Why zoom:1 (which trigger hasLayout) make all damned spaces go away?
The JsFiddle (There is some extra markup divs but ignore them, had more stuff that I removed for the sake of simplicity)
I know it's part of IE 'features (bugs)' but I was looking for something else as an answer.
回答1:
Lists
Lists are affected by layout applied either to the list (ol, ul) or to the list elements (li). Different versions of IE react differently. The most evident effects are on the list markers (fully customized lists where the markers are not required won't have these problems.) The markers are probably created by internally adding some elements that are somewhat “attached” to the list elements (usually hangs out of them) and seems rather unstable. Unfortunately, being “internal” only objects, they cannot be accessed to try to correct mis-behaviours.
The most evident effects are:
Layout applied to a list makes the markers to disappear or to be differently/wrongly positioned.
Sometimes they can be restored by changing margins on the list elements. This looks like a consequence of the fact that a layout element tends to crop internal elements hanging out of it.
Layout applied to list elements creates the same problems as above, and more (extra vertical space between list items)
A further problem is that (in ordered lists) any list element with layout seems to have its own counter. Let's say we have an ordered list with five elements where only the third has layout. We'll see this:
1... 2... 1... 4... 5...
Moreover when a list element with layout displays on multiple lines the marker is vertically aligned at the bottom (not at the top, as expected.)
Some of these problems cannot be cured, so when the markers are desired it's better to avoid layout on lists and list elements. If it's necessary to apply some dimension, this is better applied to other elements: for example a width can be applied to an external wrapper, and a height to the content of each list item.
Another common problem with lists in IE occurs when the content of any li is an anchor with display: block. In these conditions the white space between list items is not ignored and usually displayed as an extra line for each li. One of the methods to avoid this extra vertical space is to give layout to the block anchors. This also has the benefit of making the whole rectangular area of the anchors clickable.
For more detail visit : http://www.satzansatz.de/cssd/onhavinglayout.html
来源：https://stackoverflow.com/questions/16471910/ie7-ul-li-menu-with-extra-padding-why-zoom1-haslayout-makes-it-work