网上有两张著名的图片，分别以2D和3D的形式描述css盒模型：

通过这两张图，一般来说对于margin、border、background-color、background-image、padding以及width和height有较直观的了解了。

更为重要的是要了解以下几点：

1. 对于所有以“块(block)”方式呈现的元素都具备这个模型的特性，而不只是div；
2. margin是以所指定元素的父级元素（常称为“容器”）为基准的；
3. 一个元素（通常为块元素）在页面中所占的位置尺寸为：宽度= width + padding-left + padding-right + border-left-width + border-right-width + margin-left + margin-right；高度 = height + padding-top + padding-bottom + border-top-width + border-bottom-width + margin-top + margin-bottom；（部分浏览器有差异，以后再具体讨论）；
4. background-color将填满border内部的全部范围；background-image默认以图片左上角对齐border内部左上角点，然后完整显示整个图片（超出部分不予显示），如果图片尺寸不足铺满整个范围，图片默认重复自己直至铺满或超出范围；
5. background-image将叠加到background-color之上；通过指定图片的对齐方式，可以改变background-image的位置；

通过以上这些规则的组合，就能在有限的元素组合下，实现各种修饰性效果。一个简单的例子如下：

将一个15像素高，颜色为#c00的纯色图片 放入一个高度为30像素，背景色为#f00的块元素，设定图片在Y轴方向不平铺，在x轴方向平铺。结果得到一个类似下图的效果：

这是简单的由背景色与背景图组合实现的效果。根据这样的原理，当我们的文档结构有两层时，例如：<a href=”#"><span>文字</span></a>，我们可以通过由a元素的背景颜色图片和span元素的背景颜色图片组合，从而得到较为复杂的效果，例如：

这个按钮效果，用纯图片很容易实现，但是用图片实现就会面临一个问题：不通用。如果要通用，应该把文字和背景图片分离开来，同时，由于文字有多有少，因此按钮的宽度要是可变的，但是按钮并不是从左到右完全一致的背景，于是不能使用一张图片进行横向平铺，按照以前的做法，可能会使用一个一行三列的表格，第一个单元格放入左侧的图片，中间的单元格放文字和平铺的背景，右边的单元格放右侧的图片。这种思维传递到了“div+css”布局思维模式下，于是就出现了这样的结构：

<div class=”button”><div class=”left”></div><div class=”center”></div><div class=”right”></div>

这个结构的出现，就是为了实现自适应宽度的按钮，今天依然存在。实际上，使用上面的a+span的基本结构，就能实现这个效果。将中间平铺部分和左侧或右侧的边缘图片组合在一起，重复部分做得宽一些，作为a的背景图片，把另一侧的图片作为span的背景图片覆盖到a的背景图片上。组合起来看上去就成为一个整体。代码如下：

效果如下：

a {display:block;width:200px;height:36px;background:url(button.gif) no-repeat right bottom;}
a span {display:block;line-height:36px;background:url(button.gif) no-repeat left top;color:#fff;text-decoration:none;text-align:center;}

用到的背景图片如下：

这个例子很简单，但是需要对“背景组合”有足够的理解，能够想到应用。而要想到如此应用，首先是对于盒模型中的“background”足够的理解。否则，就只会想到三个div（或者其它元素组合方式），但是由于左右两个结构完全一样，为了区分它们，只好使用class或者id来标记。这就是我在上一篇中所提到的不必要的class和id。

除了利用display:block让行内元素改变为块元素从而使用盒模型特征外，在浮动的时候，也经常会用到盒模型的一些特征。再举个例子：

使用浮动布局的时候，并列呈现的浮动元素中的第一个如果设置与浮动方向相同的margin，则IE 6下会出现margin加倍的bug（这就是著名的IE6浮动边距加倍bug）。为了解决这个问题，很多人喜欢给一组浮动元素的第一个加上class=”first”，从而可以对这个元素单独应用样式。或者对这一组浮动元素加上display:inline的属性以解决这个bug。

上述两种方式都是没有使用hack选择符或者类似“_margin”这样的非标准属性的很好的hack方式。但是，如果不是非用margin不可，只要使用padding来代替margin，就能解决这个问题。或者采用与浮动方向相反的margin也可以。不需要任何额外的hack。这也是在充分理解盒模型的基础上，由于对这个bug的了解，从而在实现样式的时候直接避开，而不是出现了之后再用额外手段去hack。

对盒模型的理解，除了margin、border、padding、width、height五大属性以及两种背景的应用之外，还要了解父级元素与子元素之间的关系。比如父元素没有设置尺寸，而对子元素设置margin-top属性，在某些浏览器下，本来是想针对父元素的边缘设置margin，结果margin被设置到了父元素之外，造成父元素与外部元素的margin。这种情况，将子元素的margin改成父元素的padding，也可以在不改变表现的情况下实现相同的效果。

要想通过对盒模型特征的充分应用来减少css中的hack使用，或者以更简洁的代码实现更复杂的效果，需要对盒模型不断地尝试和总结。这是《css权威指南》之类的经典巨著也没法教给你的。

只有越理解盒模型，才能越好地利用浮动和定位来实现复杂、精确的布局。关于浮动的问题，下一次我们再一起来了解一下。

相关日志

• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-12-15 -- 前台开发从头说起：关于web标准化
• 2009-10-13 -- 关于web标准化的一些误区
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2009-04-16 -- 来自微软站点的纯CSS下拉菜单
• 2009-04-13 -- 简单、通用的JQuery Tab实现
• 2006-04-04 -- 动态实现指定图片半透明及鼠标事件
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug

一般稍微接触过css的网页设计人员，都会很快地学会三种css选择符：

• 元素选择符（例如：body 、a 、li ）
• ID选择符（例如：#head、#body、#foot）
• 类选择符（例如：.red、.item、.content）

更进一步之后，开始了解到一些进阶的选择符：

• 后代选择符（例如 #head .menu、#foot #copyright）
• 伪类选择符（例如 a:hover、a:link）

以及由这些选择符组合起来形成的综合选择符。实际上css还支持一些更丰富的选择符。但是能够被浏览器广泛支持的其实主要就是上面这几种，其它的选择符在css中往往用来区别处理不同的浏览器，或者用在jQuery一类的框架中。本文就不提了。有兴趣的可以自己在网上查一下，像属性选择符（input[type=’password’]、input[type=’radio’]）、直接后代选择符（body > div、 #head > ul）等。

实际上，有了上面列出的五种主要的选择符，通过对它们的组合，已经能够满足我们绝大部分时候的要求了，这也就意味着，相同结构下的元素，父级元素或者祖先元素只要有一点点区别，我们就能够在不借助id或者class的情况下直接访问到。例如：

<ul>
  <li><a href="#">菜单1</a>
    <ul>
      <li><a href="#">菜单1-1</a></li>
      <li><a href="#">菜单1-2</a></li>
      <li><a href="#">菜单1-3</a></li>
    </ul>
  </li>
  <li><a href="#">菜单2</a>
    <ul>
      <li><a href="#">菜单2-1</a></li>
      <li><a href="#">菜单2-2</a></li>
      <li><a href="#">菜单2-3</a></li>
    </ul>
  </li>
</ul>

这个结构是我在《来自微软的纯css下拉菜单》一文中用到的下拉菜单结构。在那个示例中，没有使用任何的class或者id，但是我们通过不同优先级的元素+后台选择符，对结构中的不同层次的ul、li、a实现了精确定位。如下面的代码：

ul {}
li {}
ul ul {}
ul ul li {}
li a {}
ul li a {}
ul li:hover ul {}

那么，在实际开发中，为什么很多网页设计人员还是离不开多如牛毛的ID和class呢（我要声明一下，我从来没有说完全抛弃id和class，我的观点是他们应该尽量少，并且由文档结构决定而不是由css需要决定）？我觉得有三方面的原因：

第一、xhtml文档结构不合理，通过元素不能体现文档的层次结构。满篇都是div。没有有效利用Hx系列标签和ul、ol、dl等不同含义的列表标签、没有有效利用p、quote、pre等标签。xhtml为我们提供了丰富的标签元素，但是如果我们只会用div，那还不如人家用table来布局的。至少他的table在一定程度上也是文档结构的体现，而满篇嵌套的div，文档结构完全没体现。

第二、css选择符掌握得不够，不善于借助文档结构层次上的细微区别，用不同的组合选择符来区别相似但其实不同的元素。例如上面的下拉菜单结构，有的人就非要用“menu”和“submenu”来区别。

第三、css选择符的优先级不清楚。css是支持继承和覆盖的，什么时候继承，什么时候覆盖。两条规则都对相同元素做出了样式规定而且样式规定重复的情况下，哪一条规则会被应用呢？这些问题不清楚，就没办法充分利用优先级实现规则的覆盖。于是只好每个要应用样式的元素都加上id或者class。关于css选择符的优先级，网上也有很多文章，我就不赘述了。

所以说，如果感觉离不了class，离不了id，那只能说明两个问题——xhtml结构不合理或者css掌握得还不够。我上一篇博文发了以后，有位朋友评论说我没做过前台开发。因为没有class和id，就不能实现css和javascript的分离。实际上，只要是长期深入学习css和javascript的朋友应该都清楚：在结构有差异的情况下，用css选择符就能精确定位某个元素；在结构完全相同的情况下，借助javascript和DOM，同样可以精确定位某个元素。

仍然以上面的下拉菜单列表为例。首先使用 ul a 对父级菜单的链接应用样式，然后用ul ul a就可以精确定位到次级菜单的链接，应用新的样式，对ul a的定义进行覆盖。那么，如果是要精确定位到第二级菜单的第二个元素呢？由于css3的选择符目前还没被广泛支持，而结构又没有差异，不借助javascript有困难了。但是借助于javascript，非常轻松，比如在jQuery中，我们可以用 $("ul ul:nth(2) li:nth(2)”) 或者 $("ul ul”).eq(1).find(“li”).eq(1) 都能得到第二个子菜单的第二个菜单元素。

css和javascript能够自己精确找到网页中的任何一个元素，那么网页自然就不用自己标识自己的每个元素。少了这层负担，我们在设计网页文档结构的时候，自然就可以抛弃一切后顾之忧，那么，xhtml中和结构无关的id和class，还有什么必要存在呢？

去除了不必要的表现元素和属性（font、center、align、height）之后，又去除了不必要的id、class、onclick、onmouseover之类的样式和行为属性，我们的网页源代码尺寸越来越小，抓一个页面下来，少量必要的结构元素之外，剩下的全是链接和内容，这样的网站，搜索引擎能不喜欢吗？

没有了后顾之忧，认清了努力方向，那么下一次我们就来谈谈css的盒模型。

相关日志

• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-15 -- 前台开发从头说起：关于web标准化
• 2009-10-13 -- 关于web标准化的一些误区
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2009-04-16 -- 来自微软站点的纯CSS下拉菜单
• 2009-04-13 -- 简单、通用的JQuery Tab实现
• 2006-04-04 -- 动态实现指定图片半透明及鼠标事件
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug

很多人对于web标准化的理解就是“DIV+CSS”，或者“IE、FF、Chrome、Opera、Safari测试无错”，或者就是“通过w3c校验”。实际上，这些都只是web标准化以后附带的一些好处或者说一些表现。web标准化的精髓并不是为了抛弃表格，或者浏览器兼容，或者通过w3c校验。有时候，标准化了的网页未必一定能达到上述这些特征。

web标准化的精髓或者说本质到底是什么呢？其实很简单，就是“结构、表现、行为分离”。这句话看起来简单，但是真的实现起来，就不那么容易了。分离，分离到什么程度算是标准？分离的目的是什么？举例来说吧。

既然要分离，那么耦合度当然是越低越好。

以样式为例。我们可以把所有的样式都放到外部CSS文件中，那么，CSS规则如何影响你的页面元素呢？有时候用到ID，有时候用到class。如果你的页面充满了ID和class，那么实际上分离得就不怎么彻底，因为你的页面上仍然有大量的ID或者class实际上是为了样式表现而存在的，他们并不是文档结构本身的要求。所以现在有“class hell”的说法。就是为了完全由外部css对页面实现精确控制，而在页面文档中加入大量，甚至过多的class。

再以行为为例。很多时候我们需要和用户交互，于是要给页面上的元素添加“onclick”，“onchange”，“onmouseover”等属性，这些属性编写在页面文档中，依赖于外部javascript。一旦外部的javascript被拿走，页面就出现执行脚本错误，甚至完全不能正常阅读。在这种情况下，javascript实际上和xhtml就没有能够解除耦合。

实际上，由于只有xhtml、css、javascript三者存在，我们不可能在网页开发中引入“面向接口编程”之类的设计模式。那么，我们所谓的彻底分离，其实从三者分离的最根本目的来说，就是要实现xhtml对另外两者不依赖。即使去除了所有的css和javascript，xhtml本身也能很好地完成自己的职责——文档结构。而css和javascript呢？依赖于xhtml是必然的。

如此一来，如何解除耦合呢？其实答案就呼之欲出了。那就是尽量避免和文档结构无关的元素嵌套，尽量去除class和事件属性。比如：

<ul>
    <li><a href="#">国内新闻</a></li>
    <li><a href="#">国际新闻</a></li>
    <li><a href="#">财经新闻</a></li>
    <li><a href="#">体育新闻</a></li>
</ul>

这样一段源代码，从文档结构的角度来理解，它就是一组彼此关联，没有先后和主次之分的列表，可以理解为列表，也可以理解为目录。

但是在css的作用下，它可以变成菜单、导航条等各种形式，如果css和javascript相结合起来，它还可以变成滑动门、三态菜单等。在这种情况下，css负责表现，javascript负责行为，而xhtml并没有因为css想实现什么样式或者javascript想实现什么交互行为而改变自己。不管css和javascript想做什么，都跟它没关系。那么实际上就真正达到了我们“彻底分离”的目的。保证了文档结构的纯粹性。这就是web标准的思维模式。

随之而来的好处，那就是页面的兼容性，不管在什么样的浏览器里，这段xhtml都是合法有效的。w3c校验也不会有任何问题。并且SEO也会非常好。因为搜索引擎想要的并不是class或者onmouseover，搜索引擎想要的只不过是链接地址和链接文字。

那么，没有class，怎么实现样式呢？没有onmouseover或者onclick，怎么实现javascript事件呢？这就需要网页开发人员的css功力和javascript功力了。

所以，越是标准化，对css和javascript的技术要求越高。反过来，css的能力达不到，或者javascript的能力达不到，那就需要借助于class（id和文档结构有关，不算在这里，后面我们再谈）、借助于onmouseover或者onclick这些与结构无关的属性来帮助实现样式或者行为。

在博客园上，暴牙齿提出“独立于根”的想法。我个人认为从文档结构的角度，并没有“独立于根”的要求。但是如果能够达到“独立于根”的开发能力，那么实现起标准化来就绝对会非常得心应手。因为连“独立于根”都能实现自己的设计样式和行为的话，有了结构的文档就更不在话下了。

理解了标准化的本质和终极目标，如何通过css和javascript来达到这个目标呢？这个问题，留到本系列以后的文章再谈。

相关日志

• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-10-13 -- 关于web标准化的一些误区
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2009-04-16 -- 来自微软站点的纯CSS下拉菜单
• 2009-04-13 -- 简单、通用的JQuery Tab实现
• 2006-04-04 -- 动态实现指定图片半透明及鼠标事件
• 2011-03-14 -- 对《优化浏览器渲染》的补充【译】
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug

但是作为一直在web开发这个领域混迹的开发人员，我从网上的文章，还有周围人的讨论中发现，很多人都把“web标准”和“div+css”完全弄混了。包括现在热卖的一些书也是这样，通篇都是“div+css”布局。严重一点的，那更是“万般皆div”。

“div+css”布局，作为web标准的一个重要部分，也是对web标准下网页布局的一个最直观布局，但是我们不应该顾名思义，以为web标准就是“div+css”布局，最后的结果就是，虽然完全抛弃了table，但是网页结构却离标准十万八千里。

web标准的本质是“结构、表现、行为”的彻底分离。在进行了多年的标准化实践以后，我越来越体会到应用web标准以后的种种好处。打开一个网页的源代码，结构清晰，标签应用准确，看到<hx>就知道这是标题，看到<p>就知道这是段落。去掉css以后，一个类似word文档的结构清晰的文件就呈现在页面上。

只有这样的网页，才能真正体现web标准化的优点。web标准化的优点主要是什么呢？加载速度快、易于维护、搜索引擎友好、减少带宽占用、利于团队分工合作……很多。采用div+css布局，做得好的话，也只不过是能够减小文件大小，提高加载速度，易于维护而已。有的文章里说“采用div+css”布局的页面更容易被搜索引擎索引，或者说“google更喜欢div+css”，这就是误区了。google喜欢的不是采用div布局或者table布局的页面，而是喜欢结构清晰良好的页面。比如一个导航条，如果采用table布局、采用flash实现、采用图片按钮等，那么google不能识别出这是对于网站来说很重要的导航条。而如果采用div布局，可以去掉很多不必要的table\tr标签，从而让对搜索引擎真正有用的两个内容——链接地址、标题更加突出。但是，只有真正符合web标准的结构，才能彻底剥离掉html代码里面的css和javascript。比如：

<a href="index.html" title="首页" onmouseover="highLight(this)"
 style="font-weight:bold;color:red">返回首页</a>

这样一段代码，其中对搜索引擎有用的只不过是“index.html”和“首页”罢了。符合web标准的html应该是这样：

<a href="index.html" title="首页">返回首页</a>

css怎么办呢？放到外部css文件里去，鼠标滑过的效果呢？放到外部js里去，为网页元素附加事件，这属于行为，应该是javascript的职责范围。不应该放到文档结构里。

刚才是一个结构表现行为混合的反面例子，除了三块不分开以外，现在网上流传很广的很多div+css布局的页面还存在另外一个问题，就是html标签使用不合理，虽然使用了div+css布局，但是html丝毫不能体现页面结构。比如：

<div id="wrap">
    <div id="head">
        <div id="logo">
            <img src="logo.gif" border="0" width="250" height="60" />
        </div>
    </div>
</div>

像这样的例子，现在互联网上遍地都是，做成这样，你可以说你抛弃了表格，采用了div+css布局，但是这样的div布局，有什么意义呢？除了抛弃表格赶了现在的时髦以外。这里的这张图是网站的标识，也就是说，搜索引擎来到这里，应该得到的是网站的名称之类的信息。那么结构合理的站点怎么做的呢？

<div id="wrap">
    <div id="head">
        <h1>网站名称</h1>
    </div>
</div>

作为网站标题，也就是一本书的书名，一篇文章的标题，在word里面我们一般会设置“标题一”，在现阶段的HTML规范里，那就对应着一级标题<h1>，所以这里理所当然使用每个页面都应该有且仅有一个的<h1>。

可是设计图里这个地方不显示网站的标题而是现实网站的LOGO，怎么办呢？这就不属于文档结构的问题，而是页面表现的问题了，应该是css的职责。实现起来其实也不难：

h1 {background:(logo.gif) no-repeat;width:250px;height:60px;text-indent:-9999px;}

在web标准中，文档结构是首要问题，你的HTML应该体现你的网页的文档结构和层次，从每个部分的先后、重要程度、主次程度出发，考虑是段落还是标题？是列表还是引用？从而使用对应的标签。而不是为了实现设计样式，把重要的放下面，把标题改成图片。当然其中最失败的，就是到处都是div。

HTML中提供了那么多的标签，本意就是每个标签对应文档的不同部分，每个标签有各自的用途和意义。如果一切都从布局需要出发，只要是要应用样式的就来个div，那HTML还有什么意义？只需要<html>、<head>、<body>加上<div>、<a>就够了。还要<ul>、<ol>、<dl>、<p>、<quote>这些干什么呢？

最后还有一个误区，那就是——div+css布局才是标准化，用了table就是不标准。w3c从来没有说过table是不推荐使用的标签，更没有说过web标准要求禁止table。table的作用，是呈现数据，结构化的数据，在数据库中是怎么存储的？当然是以数据表的形式。那么这些数据要呈现到页面上，同样大部分时候仍然是以表格形式。在这个时候，就应该使用表格，使用table。

在web标准刚刚热火起来的时候，主要是针对大家已经使用多年形成依赖的table布局和table嵌套而把用div进行网页块划分和用table进行网页块划分的两种页面布局方式进行比较，从而才出现了“div布局”和“table布局”的概念。实际上，比这种叫法更准确的，应该是“css布局”和“html布局”。

一律使用div不是标准，标准也从来不禁用table。div只是web标准中用来实现网页布局的重要标签，实际上没有任何效果是必须依赖div的。所有的效果都是由css实现的，不管是div还是p，css都能让他们呈现出同样的效果。而table呢？应该回归到它本来的作用——呈现表格形式的数据。

我以前一直认为这只是网络上网页设计自学者和一些网页设计网站混淆了概念，搞错了重点。但是当我回到高校，从事电子商务开发方面的教学时，我才发现，问题已经蔓延到了高校教材、课堂教学中了。

现在其实有很多网页设计师，UI工程师和程序员都很努力地致力于web标准的推广。我想说的是，希望大家在传播web标准理念的时候，不要光顾技术细节、技巧方面的问题了，而忽略了web标准的本质——先进的设计模式和开发理念。

相关日志

• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-12-15 -- 前台开发从头说起：关于web标准化
• 2009-04-16 -- 来自微软站点的纯CSS下拉菜单
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2010-10-24 -- 在WebKit中并行加载外部脚本【译】
• 2010-10-22 -- HTML验证的价值探讨【译】
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2010-06-02 -- HTML5时代的div

先看一下效果（这是我重新实现的）：

下面是实现方法：

首先是菜单的XHTML代码：

<ul>
  <li><a href="#">菜单一</a></li>
  <li><a href="#">菜单二</a>
    <ul>
      <li><a href="#">子菜单一</a></li>
      <li><a href="#">子菜单二</a></li>
      <li><a href="#">子菜单三</a></li>
    </ul>
  </li>
  <li><a href="#">菜单三</a></li>
  <li><a href="#">菜单四</a>
    <ul>
      <li><a href="#">子菜单一</a></li>
      <li><a href="#">子菜单二</a></li>
      <li><a href="#">子菜单三</a></li>
    </ul>
  </li>
  <li><a href="#">菜单五</a></li>
</ul>

不设置任何CSS类，实在是干净到极点了（当然，考虑到实际应用的复杂性，我估计你不可能真的什么都不加。要么把这段代码放到一个特定的容器里，要么给第一层的ul加一个id或者class。

假设这是在一个新的HTML文档里，那么我们现在没有任何的CSS定义，这时候的网页显示效果是这样的：

在我们的下拉菜单中，不需要内补丁、外边距这些东西，即使需要，我们也要自己重新设置，所以我们首先添加第一条规则：

ul {
    margin: 0;padding: 0;
}

为了跨浏览器兼容，必须同时把外边距和内补丁都设置为0，因为有的浏览器默认使用外边距，有的则默认使用内补丁。这样设置以后，页面上可以看到两层列表项前面的缩进都没了，实心和空心的列表符号也不见了。然后设置第二条规则：

ul li {
    float: left;
    display: inline;
    font: 0.9em Arial, Helvetica, sans-serif;
    height: 30px;
    width: 100px;
    list-style: none;
}

这是让原本各占一行的li元素变成嵌入式（inline）显示，另一种说法是把list-item元素变成行内元素。总而言之就是让li不要各占一行，并列起来，这样才能成为菜单。设置后，效果如下：

这样就得到了下拉菜单的雏形，当然了，外观很丑陋，下拉功能也还没实现。这里要说明的是，最好给菜单项设置高度和宽度，否则有可能出现不可预料的结果（取决于页面或容器的宽度）。为了让菜单项看起来像菜单，我们继续添加规则：

ul li a {
    color: #FFF;
    text-decoration: none;
    line-height: 29px;
    width: 91px;
    margin: 0;
    padding: 0 0 0 8px;
    display: block;
    border-right: solid 1px #ccc;
    border-bottom:solid 1px #ccc;
    background: #808080;
}

这一条规则比较长，从作用上说呢，就是加上背景和菜单间的隔离线，把默认有下划线蓝色的文字变成白色无下划线。增加了规则后的效果：

从外观上，这就已经是我们最终的下拉菜单样式了。不过，我们还要在细节上修饰一下，比如让子菜单和一级菜单的样式有所区别（当然了，由于字体设置的0.9em，所以在文字大小上已经有区别了，但是还不够，而且对于中文来说，很多时候我们未必能通过文字大小来区别，因为适合中文的常规文字大小就12px和14px而已），所以我们修改一下子菜单的背景色，并且让子菜单比一级菜单的高度要小一些。规则：

ul li ul li { height:25px; }
ul li ul li a {
    background: #666;
    line-height:24px;
}

这里包含两条规则，第一条是将子菜单的列表项目高度由之前统一设置的30px减小为25，第二是将子菜单项的背景改为#666，并且文字行高对应地减小到24设置完成后（列表项高度-1，减去的1正好是上边框的1像素），效果如下：

通常我们鼠标滑过某个菜单项的时候，要让它跟其它项目有所区别（表示当前菜单处于激活状态，术语叫“高亮” ，所以我们对一级菜单的鼠标滑过样式做一下定义：

ul li a:hover { background: #666; }

注意，这里为鼠标滑过时设置的背景色和子菜单的背景色一样，原因？看效果就知道了：

这里的第二个菜单项就是鼠标滑过时候的样式，这样就跟弹出的（现在还不会弹出）子菜单背景色一致了。现在整个菜单的样式都设置完了，但是，这只是静态的菜单啊，我们要的是会动的。所以工作还没完成。接下来是什么呢？当然是默认情况下把二级菜单隐藏起来。我们要写JS来隐藏他们吗？No！样式如下：

ul li ul { visibility: hidden; }

这样，子菜单并不是像“display:none”一样不显示，它还是在那个位置，文档结构什么的都没有发生任何改变，只是看不到它而已，而且下拉菜单中的链接当然也没不可以点击。

最后一条规则，让鼠标滑过有下拉项的时候，显示下拉菜单。当然我们实际设置的是：如果某一个下拉菜单的父级元素（一级菜单项）被鼠标滑过，那么就让该下拉菜单可以被看见：

ul li:hover ul { visibility: visible; }

这样就完成了整个设置下拉菜单制作，当然你还可以进一步修饰这个菜单，比如我们应该让子菜单中的项目在鼠标滑过的时候也变色：

ul li ul li a:hover { background: #333; }

最终效果

要强调的一点：这个下拉菜单在各主流浏览器（IE6以下的版本除外）中的外观及行为都是完全一致的。兼容性非常好。为什么不支持IE6呢？因为IE8都出来了，我们是不是应该彻底抛弃那个给网页设计师带来无限痛苦的万恶的IE6了？

如果IE6的兼容性对你的站点来说非常重要，那么你可以通过Javascript来修正。

本文参考：http://www.microsoft.com/china/expression/newsletter/2008-11/article05.aspx

相关日志

• 2009-12-21 -- 前台开发从头说起：理解css盒模型
• 2009-12-16 -- 前台开发从头说起：谈谈CSS选择符
• 2009-12-15 -- 前台开发从头说起：关于web标准化
• 2011-03-12 -- 自适应的多列图文混排改进
• 2010-10-30 -- webkit中BFC元素临近浮动元素时的边距bug
• 2010-10-20 -- clearfix改良及overflow:hidden详解【译】
• 2009-10-13 -- 关于web标准化的一些误区
• 2009-06-22 -- Whatever:hover – 无需javascript让IE支持丰富伪类
• 2009-04-13 -- 简单、通用的JQuery Tab实现
• 2006-04-04 -- 动态实现指定图片半透明及鼠标事件