li标签之间的空隙问题，转 原文地址：http://www.cnblogs.com/laogao/archive/2012/08/13/2636419.htmlcss li 空隙问题
css li 空隙问题
IE6/7的Bug：纵向排列的li中加浮动元素产生向下3px的空隙
最近做页面时，经常碰到用 li 标签做纵向列表的时候，会在li的下面产生3px的空隙，之前也碰到过，但都用简单的方法解决了。搜索了一下，网上已经有人给出一些解决方案，但细看之后发现他们的解决方案和找到的原因都有些问题，甚至是错误。要么只单纯地提出问题，解决问题，没有更详细的探讨。所以这二天抽空写了一个demo，对这个bug做了一点研究。
bug实例如下：
li与li之间应该是没有任何空隙的，因为我没有设置margin-top，或margin-bottom的值。这就是3px的bug。
HTML原代码 ：
<ul class="list-1"> <li> <span>我有浮动</span> <a href="#">我有浮动</a> <strong class="red">这里所有的元素都浮动</strong></li> <li> <em>inline元素</em> <span>Span float:left;</span> <a href="http://hadaiye.blog.163.com/blog/#">A float:left;</a> <div class="red">我不浮动，且不是最后一个元素</div> <strong>Strong float:right;</strong> </li> <li> <span>我有浮动</span> <a href="http://hadaiye.blog.163.com/blog/#">我有浮动</a> <strong>我有浮动</strong> </li> </ul>
主要的CSS样式： .list-1{width:502px; padding-bottom:30px;} .list-1 li{list-style:none; border:1px solid #ccc; padding:5px; background:#FFC; line-height:1.7; width:500px;} .list-1 li span{padding:3px;margin-right:5px; background:#f2f2f2; float:left; } .list-1 li a{padding:3px;margin-right:5px; background:#9CF; float:left;} .list-1 li strong{padding:3px; background:#C6FDCB; float:right; }
并不是所有的li都会有这个问题，只有纵向排列的li才有可能出现，触发的情况有2种： 1.li中所有的子元素均浮动，并设置了宽、高或zoom中的一项或多项。 2.li中最后一个不浮动的子元素为块级元素，且不是最后一个子元素，同时li设置了宽、高或zoom中的一项或多项。PS：宽width( min-width, max-width), 高height(min-height, max-height)
有必要解释一下这2个结论得出的过程： li元素默认是block的，纵排的时候不需要加float，可以给ul加一个宽度——以此为基础进行测试，因为这是正常的正确的coding思路。
根据大家的经验，li中没有浮动的子元素不会产生3px的bug，那么这个条件就不再考虑。重点考虑子元素全部浮动 和浮动与非浮动混合这二种情况。为了便于解释，把 ”设置宽、高或zoom中的一项或多项“ 简称为 ”设置宽/高“
第1种情况： 子元素全部浮动，在不设置宽/高的情况下，不会有bug；一旦设置宽/高，bug就产生了。
【友情PS：浮动的元素都成为了块级元素，浮动元素会脱离了正常的文档流，但不完全脱离，它不会跑到父元素的外面去，但是，它们的位置会空出来，父元素却不能完全拥有它们，此时的父元素没有了高度。如果你在FF下用Firebug查看，它的高度是0，宽度是其父元素的宽度（为了不混淆视听，图就不放了，大家自己可以试一下）。在这种情况下设置高或宽，li元素就能在形式上拥有元素。设置zoom:1所达到的效果也是一样的。】
第2种情况： 这种就比较复杂。不浮动的元素可以是block, inline,和 line-block的任何一种。根据测试inline 和 inline-block可归为一类（以下均用inline 类代表inline 和 inline-block ）。混搭的情况又有 ”非浮动元素都是inline类元素“ 和 ”非浮动元素既有inline类又有block元素“ 2种。
非浮动元素都是inline类元素的情况下，不会bug，加上高/宽也不会bug。非常好！
非浮动元素既有inline类又有block元素的情况下，会出现的情况很多，但不管怎么组合，最后一个不浮动是inline类元素，就不会出bug，不管它在哪个位置，前面有多少非浮动的元素；最后一个不浮动的是block元素，且是最后一个元素（代码上，不是指表现上），也不会出Bug。只有最后一个不浮动的是block元素，且不是最后一个元素才会有bug。
经测试，有怀疑性的margin, padding, border, background 在何种情况下都不影响3px bug的产生，于是就有了上面的2个结论。
推测原因： 根据经验推测此3px bug 产生和 IE 特有的 haslayout 有关，因为在 ie8（ie取消了haslayout）和其它浏览器中没有这个问题。但是又不完全依赖haslayout，并不是所有触发haslayout的属性都会产生3px的bug。
从解决方法上来看，这个bug与float元素的显示有关，当li的子元素均有浮动，其文档流就改变了，当li重新拥有高宽后，bug就产生了（可能与并没有真正拥有子元素有关）。但是，当浮动的元素被其它因素影响(加入了非浮动的元素，或浮动元素有vertical- align属性）时，bug就有可能消失。
但目前任何一款调试工具都没法看出这多出来的3px是从哪里产生的，真正的原因估计只有ie自己知道了（我觉得跟ie中文档流的表现有关，另一个诡异的3px问题，也跟浮动有关）。
解决方案： 找到了起因就有了解决方案，这里提供4种解决思路。
1、给li添加浮动，如有需要可设置宽度。
PS：给li加浮动，让它和子元素一样浮动起来，并真正拥有子元素，而不止是形式上
2、把li设置成display:inline-block（变成inline也可以，但是样式就杯具了）
3、为li中所有元素都设置vertical-align值，此值可为top, bottom, middle, text-top, text-bottom, middle, sub, super中的一项（有博文说可设置vertical-align的任何值，这是错的，有些值不能解决bug，比如auto，centrial ）
4、从代码设计上避免bug的产生：在li中有意识地加入inline 或 inline-block的元素，放在哪里都可以；或者使最后一个元素不浮动，不管它是不是块级元素、前面还有没有不浮动的元素
一点补充说明： 之前看到一些博文中这个bug产生的原因是“ li的子元素浮动，并且li设置了以下CSS属性之一：width、height、zoom、padding-top、padding-bottom、margin-top、margin-bottom”，这种说法不够准确，而且有误导。因为它没有指出子元素浮动是个别的还是全部的，个别浮动不一定会触发此bug。它所说的li的设置中有margin 和 padding，而这二项是不会对bug的产生起任何作用的，如果没有width, height, zoom中的一项，加不加padding 和 margin都不会产生3px问题。
还有一篇博文中说“通过添加相应的CSS属性来激发li的haslayout来解决”，这种说法也不对。因为在bug产生的时候haslayout就已经存在了，从链接中的博文可以看到，bug产生的时候，它对li设置了width:400px，就已经触发了li的haslayout属性。对于可触发haslayout的因素可参见百度百科的haslayout。
如果你还发现其它情况 ，请通过评论或邮件告诉我，谢谢~~
IE6/7的Bug：纵向排列的li中加浮动元素产生向下3px的空隙
最近做页面时，经常碰到用 li 标签做纵向列表的时候，会在li的下面产生3px的空隙，之前也碰到过，但都用简单的方法解决了。搜索了一下，网上已经有人给出一些解决方案，但细看之后发现他们的解决方案和找到的原因都有些问题，甚至是错误。要么只单纯地提出问题，解决问题，没有更详细的探讨。所以这二天抽空写了一个demo，对这个bug做了一点研究。
bug实例如下：
li与li之间应该是没有任何空隙的，因为我没有设置margin-top，或margin-bottom的值。这就是3px的bug。
HTML原代码 ：
<ul class="list-1"> <li> <span>我有浮动</span> <a href="#">我有浮动</a> <strong class="red">这里所有的元素都浮动</strong></li> <li> <em>inline元素</em> <span>Span float:left;</span> <a href="http://hadaiye.blog.163.com/blog/#">A float:left;</a> <div class="red">我不浮动，且不是最后一个元素</div> <strong>Strong float:right;</strong> </li> <li> <span>我有浮动</span> <a href="http://hadaiye.blog.163.com/blog/#">我有浮动</a> <strong>我有浮动</strong> </li> </ul>
主要的CSS样式： .list-1{width:502px; padding-bottom:30px;} .list-1 li{list-style:none; border:1px solid #ccc; padding:5px; background:#FFC; line-height:1.7; width:500px;} .list-1 li span{padding:3px;margin-right:5px; background:#f2f2f2; float:left; } .list-1 li a{padding:3px;margin-right:5px; background:#9CF; float:left;} .list-1 li strong{padding:3px; background:#C6FDCB; float:right; }
并不是所有的li都会有这个问题，只有纵向排列的li才有可能出现，触发的情况有2种： 1.li中所有的子元素均浮动，并设置了宽、高或zoom中的一项或多项。 2.li中最后一个不浮动的子元素为块级元素，且不是最后一个子元素，同时li设置了宽、高或zoom中的一项或多项。PS：宽width( min-width, max-width), 高height(min-height, max-height)
有必要解释一下这2个结论得出的过程： li元素默认是block的，纵排的时候不需要加float，可以给ul加一个宽度——以此为基础进行测试，因为这是正常的正确的coding思路。
根据大家的经验，li中没有浮动的子元素不会产生3px的bug，那么这个条件就不再考虑。重点考虑子元素全部浮动 和浮动与非浮动混合这二种情况。为了便于解释，把 ”设置宽、高或zoom中的一项或多项“ 简称为 ”设置宽/高“
第1种情况： 子元素全部浮动，在不设置宽/高的情况下，不会有bug；一旦设置宽/高，bug就产生了。
【友情PS：浮动的元素都成为了块级元素，浮动元素会脱离了正常的文档流，但不完全脱离，它不会跑到父元素的外面去，但是，它们的位置会空出来，父元素却不能完全拥有它们，此时的父元素没有了高度。如果你在FF下用Firebug查看，它的高度是0，宽度是其父元素的宽度（为了不混淆视听，图就不放了，大家自己可以试一下）。在这种情况下设置高或宽，li元素就能在形式上拥有元素。设置zoom:1所达到的效果也是一样的。】
第2种情况： 这种就比较复杂。不浮动的元素可以是block, inline,和 line-block的任何一种。根据测试inline 和 inline-block可归为一类（以下均用inline 类代表inline 和 inline-block ）。混搭的情况又有 ”非浮动元素都是inline类元素“ 和 ”非浮动元素既有inline类又有block元素“ 2种。
非浮动元素都是inline类元素的情况下，不会bug，加上高/宽也不会bug。非常好！
非浮动元素既有inline类又有block元素的情况下，会出现的情况很多，但不管怎么组合，最后一个不浮动是inline类元素，就不会出bug，不管它在哪个位置，前面有多少非浮动的元素；最后一个不浮动的是block元素，且是最后一个元素（代码上，不是指表现上），也不会出Bug。只有最后一个不浮动的是block元素，且不是最后一个元素才会有bug。
经测试，有怀疑性的margin, padding, border, background 在何种情况下都不影响3px bug的产生，于是就有了上面的2个结论。
推测原因： 根据经验推测此3px bug 产生和 IE 特有的 haslayout 有关，因为在 ie8（ie取消了haslayout）和其它浏览器中没有这个问题。但是又不完全依赖haslayout，并不是所有触发haslayout的属性都会产生3px的bug。
从解决方法上来看，这个bug与float元素的显示有关，当li的子元素均有浮动，其文档流就改变了，当li重新拥有高宽后，bug就产生了（可能与并没有真正拥有子元素有关）。但是，当浮动的元素被其它因素影响(加入了非浮动的元素，或浮动元素有vertical- align属性）时，bug就有可能消失。
但目前任何一款调试工具都没法看出这多出来的3px是从哪里产生的，真正的原因估计只有ie自己知道了（我觉得跟ie中文档流的表现有关，另一个诡异的3px问题，也跟浮动有关）。
解决方案： 找到了起因就有了解决方案，这里提供4种解决思路。
1、给li添加浮动，如有需要可设置宽度。
PS：给li加浮动，让它和子元素一样浮动起来，并真正拥有子元素，而不止是形式上
2、把li设置成display:inline-block（变成inline也可以，但是样式就杯具了）
3、为li中所有元素都设置vertical-align值，此值可为top, bottom, middle, text-top, text-bottom, middle, sub, super中的一项（有博文说可设置vertical-align的任何值，这是错的，有些值不能解决bug，比如auto，centrial ）
4、从代码设计上避免bug的产生：在li中有意识地加入inline 或 inline-block的元素，放在哪里都可以；或者使最后一个元素不浮动，不管它是不是块级元素、前面还有没有不浮动的元素
一点补充说明： 之前看到一些博文中这个bug产生的原因是“ li的子元素浮动，并且li设置了以下CSS属性之一：width、height、zoom、padding-top、padding-bottom、margin-top、margin-bottom”，这种说法不够准确，而且有误导。因为它没有指出子元素浮动是个别的还是全部的，个别浮动不一定会触发此bug。它所说的li的设置中有margin 和 padding，而这二项是不会对bug的产生起任何作用的，如果没有width, height, zoom中的一项，加不加padding 和 margin都不会产生3px问题。
还有一篇博文中说“通过添加相应的CSS属性来激发li的haslayout来解决”，这种说法也不对。因为在bug产生的时候haslayout就已经存在了，从链接中的博文可以看到，bug产生的时候，它对li设置了width:400px，就已经触发了li的haslayout属性。对于可触发haslayout的因素可参见百度百科的haslayout。
如果你还发现其它情况 ，请通过评论或邮件告诉我，谢谢~~
