译文：:nth-child 和 :nth-type-of 的区别

假设有以下 HTML 代码：

<section>
     <p>Little</p>
     <p>Piggy</p>  <!--目标元素-->
</section>

以下代码得到的效果一样：

p:nth-child(2){color:red;} 
p:nth-of-type(2){color:red;}

结果虽然相同，但是两者本身还是有所区别的。

:nth-child 选择符 从词义上来说，表示，

选择满足以下条件的元素：

• 1. 是一个段落元素 p
• 2. 是父元素的第二个子元素

:nth-of-type 选择符 从词义上来看，表示：

• 1. 选择父元素的第二个段落元素 p

:nth-of-type 是… 怎么说好呢，哈~ … 较少条件要约的。

假设结构变化如下：

<section>
     <h1>World</h1>
     <p>Little</p>
     <p>Piggy</p>  <!--目标元素-->
</section>

那么，这种方式就“破”了：

p:nth-child(2){color:red;}

但是，这个还是”能用”的：

p:nth-of-type(2){color:red;}

所谓的“破”，意思是上面的 :nth-child 选择符现在选到的是 “Little”，而不是 “Piggy”，因为这个元素满足以下所有条件：

• 1) 它是第二个字元素
• 2）它是一个段落元素 p

所说的“能用”，意思是 “Piggy” 仍然被选中，因为它是它父元素下的第二个段落元素 p 。

如果在 h1 之后增加一个 h2，那么 :nth-child 选择符就什么也选中不了了，因为那时第二个子元素就不再是段落元素 p 了。但是 :nth-of-type 仍然还是有效的。

我感觉 :nth-of-type 相对不那么脆弱，而且总的来说更加有用，尽管 :nth-child 更加常见（作者个人意见）。你有多少时候在想“我想选择父元素的第二个子元素，如果它恰巧是个段落元素 p” 这事呢？可能有那么几次，但是更多的可能是你想“选中第二个段落”或者“每隔两行选择一行 (select every third table row)”，也就是说 :nth-of-type 是更加好的一个选择（再次声明，作者个人意见）。

我发现当我抱怨“为什么 :nth-child 选择符不行？”时，绝对多数的情况是因为在选择符前限定了标签，而那个位置的子元素不是那个标签。因此在使用 :nth-child 时，我觉得最好还是只指定父元素并且不要用标签来限制 :nth-child 。

dl :nth-child(2) {} /* 推荐 */ 
dd:nth-child(2) {} /* 不是很好 */

当然，具体情况还得具体分析。（我咋这么不喜欢这句话呢 – 糖伴西红柿）

浏览器对于 :nth-of-type 的支持是相当不错的…Firefox 3.5+, Opera 9.5+, Chrome 2+, Safari 3.1+, IE 9+。如果需要更多的支持，jQuery 应该会挺你的（使用选择符，添加一个类名，使用类名来添加样式 $(“selector:nth-child(xxxxx)”).addClass(“someClass”)），但是实际上 jQuery 却放弃了对 :nth-of-type 的支持，这很奇怪啊，据说是因为 :nth-of-type 的使用率很低。有个插件可以使得 jQuery 支持它。

相关：不要忘了它这些了不起姊妹们 :first-of-type :last-of-type :nth-last-of-type 和 :only-of-type 。更多请看这里。

这里有一个 Lea Verou 做的可视化示例。

原文：The Difference Between :nth-child and :nth-of-type

译文：:nth-child 和 :nth-type-of 的区别

div

HTML Spec: “The div element has no special meaning at all.”

这个标签是我们见得最多、用得最多的一个标签。本身没有任何语义，用作布局以及样式化或脚本的钩子(hook)。

section

HTML Spec: “The section element represents a generic section of a document or application. A section, in this context, is a thematic grouping of content, typically with a heading.”

与 div 的无语义相对，简单地说 section 就是带有语义的 div 了，但是千万不要觉得真得这么简单。section 表示一段专题性的内容，一般会带有标题。看到这里，我们也许会想到，那么一篇博客文章，或者一条单独的评论岂不是正好可以用 section 吗？接着看：

“Authors are encouraged to use the article element instead of the section element when it would make sense to syndicate the contents of the elemen.”

当元素内容聚合起来更加言之有物时，应该使用 article 来替换 section 。

那么，section 应该什么时候用呢？再接着看：

“Examples of sections would be chapters, the various tabbed pages in a tabbed dialog box, or the numbered sections of a thesis. A Web site’s home page could be split into sections for an introduction, news items, and contact information.”

section 应用的典型场景有文章的章节、标签对话框中的标签页、或者论文中有编号的部分。一个网站的主页可以分成简介、新闻和联系信息等几部分。其实我对这里传达信息很感兴趣，因为感觉 section 和下面要介绍的 artilce 更加适用于模块化应用，这个话题以后会出篇专门的文章来讨论，这里暂时略过。

要注意，W3C 还警告说：

“The section element is not a generic container element. When an element is needed for styling purposes or as a convenience for scripting, authors are encouraged to use the div element instead. A general rule is that the section element is appropriate only if the element’s contents would be listed explicitly in the document’s outline.”

section 不仅仅是一个普通的容器标签。当一个标签只是为了样式化或者方便脚本使用时，应该使用 div 。一般来说，当元素内容明确地出现在文档大纲中时，section 就是适用的。

<article>
 <hgroup>
  <h1>Apples</h1>
  <h2>Tasty, delicious fruit!</h2>
 </hgroup>
 <p>The apple is the pomaceous fruit of the apple tree.</p>
 <section>
  <h1>Red Delicious</h1>
  <p>These bright red apples are the most common found in many
  supermarkets.</p>
 </section>
 <section>
  <h1>Granny Smith</h1>
  <p>These juicy, green apples make a great filling for
  apple pies.</p>
 </section>
</article>

article

HTML Spec: “The article element represents a self-contained composition in a document, page, application, or site and that is, in principle, independently distributable or reusable, e.g. in syndication.”

article 是一个特殊的 section 标签，它比 section 具有更明确的语义, 它代表一个独立的、完整的相关内容块。一般来说， article 会有标题部分(通常包含在 header 内)，有时也会 包含 footer 。虽然 section 也是带有主题性的一块内容，但是无论从结构上还是内容上来说，article 本身就是独立的、完整的。

HTML Spec 中接着又列举了一些 article 适用的场景。 “This could be a forum post, a magazine or newspaper article, a blog entry, a user-submitted comment, an interactive widget or gadget, or any other independent item of content.”

当 article 内嵌 article 时，原则上来说，内部的 article 的内容是和外层的 article 内容是相关的。例如，一篇博客文章中，包含用户提交的评论的 article 就应该潜逃在包含博客文章 article 之中。

问题是怎么才算“完整的独立内容”？有个最简单的判断方法是看这段内容在 RSS feed 中是不是完整的。看这段内容脱离了所在的语境，是否还是完整的、独立的。

例子：

<article>
 <header>
  <h1>The Very First Rule of Life</h1>
  <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <footer>
  <a href="?comments=1">Show comments...</a>
 </footer>
</article>

<article>
 <header>
  <h1>The Very First Rule of Life</h1>
  <p><time pubdate datetime="2009-10-09T14:28-08:00"></time></p>
 </header>
 <p>If there's a microphone anywhere near you, assume it's hot and
 sending whatever you're saying to the world. Seriously.</p>
 <p>...</p>
 <section>
  <h1>Comments</h1>
  <article>
   <footer>
    <p>Posted by: George Washington</p>
    <p><time pubdate datetime="2009-10-10T19:10-08:00"></time></p>
   </footer>
   <p>Yeah! Especially when talking about your lobbyist friends!</p>
  </article>
  <article>
   <footer>
    <p>Posted by: George Hammond</p>
    <p><time pubdate datetime="2009-10-10T19:15-08:00"></time></p>
   </footer>
   <p>Hey, you have the same first name as me.</p>
  </article>
 </section>
</article>

总结

div section article ，语义是从无到有，逐渐增强的。div 无任何语义，仅仅用作样式化或者脚本化的钩子(hook)，对于一段主题性的内容，则就适用 section，而假如这段内容可以脱离上下文，作为完整的独立存在的一段内容，则就适用 article。原则上来说，能使用 article 的时候，也是可以使用 section 的，但是实际上，假如使用 article 更合适，那么就不要使用 section 。nav 和 aside 的使用也是如此，这两个标签也是特殊的 section，在使用 nav 和 aside 更合适的情况下，也不要使用 section 了。

对于 div 和 section、 article 以及其他标签的区分比较简单。对于 section 和 article 的区分乍看比较难，其实重点就是看看这段内容脱离了整体是不是还能作为一个完整的、独立的内容而存在，这里面的重点又在完整身上。因为其实说起来 section 包含的内容也能算作独立的一块，但是它只能算是组成整体的一部分，article 才是一个完整的整体。

因为其实有些时候每个人都有自己的看法，所以难免有难于决断的时候，怎么办？

在 HTML5 设计原理 中，有一条是专门用来解决类似情况的：

最终用户优先(Priority of Constituencies)

“In case of conflict, consider users over authors over implementors over specifiers over theoretical purity.” 一旦遇到冲突，最终用户优先，其次是作者，其次是实现者，其次标准制定者，最后才是理论上的完满。

推荐各位多读几遍 HTML5 设计原理，这才是纷繁世界背后的最终奥义。

译文：CSS Sprites：鱼翅还是三鹿？

无处不在的 CSS sptites － 为数不多的几个可以直接跳过”流行”这个过程，而可以马上并且牢牢地跻身于最佳 CSS 实践之中的几个技术之一。虽然它真正流行是在 A List Apart 解释并认可这个技术之后，但是早在 2003 年 7 月份，Peter Stanicek 就已经开始谈论它了。

目前大多数的开发人员对这个技术都有相当地掌握，也有很多关于它的教程和文章。几乎所有的文章中都宣称设计师和开发人员都应该使用 CSS sprite 来减少 HTTP 请求数，并且节省一些流量。这个技术被大量网站使用，包括使用了大型 sprite 的 Amazon .

但是这些被广泛热议的好处真的是值得的吗？设计师们是否在没有全面考虑到所有情况的情况下，在盲目地使用这个技术呢？设计师们是不是过于关注 CSS sprite 的流行，而忽略了其它应该仔细斟酌的因素了呢？ 这篇文章会讨论下使用 CSS sprite 的好处和坏处，尤其关注”滥用” sprites 的情况，而且会解释下为什么“滥用” sprite 其实是浪费时间。

浏览器缓存所有图片

sprite 技术的其中一个好处是图片的加载时间(在有许多 sprite 时，单张图片的加载时间)。由所需图片拼成的一张 GIF 图片的尺寸会明显小于所有图片拼合前的大小。单张的 GIF 只有相关的一个色表，而单独分割的每一张 GIF 都有自己的一个色表，这就增加了总体的大小。因此，单独的一张 JPEG 或者 PNG sprite 在大小上非常可能比把一张图分成多张得来的图片总尺寸小。但是这真的有想象的那么好吗？

一般来说，浏览器会缓存所有的图片 – 无论图片 sprite 与否。sprite 技术只是在页面第一次加载的时候才会节省带宽，同时缓存也会对使用相同图片的其他页面有效。

Firefox 缓存显示的浏览器缓存的来自 amazon.com 的图片(在 Firefox 地址栏输入 “about:cache” 来查看)。

考虑到现在的普遍网速已经比 2003-2004 年时提出这个技术的时候要快多了，因此大量使用 sprite 技术就不是那么必要了。有一点需要明确，不是说不应该用 sprite，而是不应该为了有限的好处来滥用这个技术。

拼合图片的时间成本会增加

想象一下一个有三个状态的图片按钮是怎么制作的：代表不同的状态的图片需要临近放置在一起组成一张图片。在使用 Photoshop 或其他软件切图时，不同的状态并不会在一起；需要把他们单独切出来再合并为一张图片。

如果其中任一个图片状态需要改变，整个图片就需要重新制作保存。对一些设计师来说这不是什么问题，也许他们会单独保留不同按钮状态的源文件，这样需要合并的时候就简单了。但是这个过程有点复杂，远没有切出一个单独图片来的简单。

为了节省几 k 的流量和几个服务器请求(还只发生在第一次加载页面时)，sprite 技术是否真的值得？

编码和维护的时间成本会增加

图片切片输出之后，麻烦依然存在。虽然习惯这个过程之后，按钮 sprite 可以很简单地编码到 CSS 中，但是其他的 sprites 就不这么简单了。

单一的一个按钮一般会是个有定宽的 <ul> 元素。假如按钮的 sprite 是彼此独立的，就比较简单：<ul> 的宽高会和列表项和锚点的宽高一致，每个状态的 sprite 对齐摆放。sprite 的位置也可以很容易地根据每个按钮的宽高计算出来。

但是遇到之前提到的，像 Amazon 或者 Google 用到的大型 sprite 的情况时，会怎么样呢？你能想象到到维护这么一个文件，并且在 CSS 中改变 sprite 项的位置会是什么样吗？还有第一次创建 CSS 代码的情况？相对于一个可以轻松计算出来状态位置的简单按钮来说，大型的 sprite 会导致无尽地测试和图片状态的重新摆放。

一些用于定位 Google 的 sprite 图片的样式

Amazon 的 sprites 确实节省了至少 30 个 HTTP 连接，性能方面也确实有了很大的提高。但是把这些好处拿来和开发以及维护成本做个比较，再把缓存和网速等因素考虑进来，决定使用如此大型的 sprites 也许就不那么令人信服了。

Sprites 是否真的需要“维护”？

当然了，有些人不觉得 sprite 是首要引起头疼的问题。大部分情况下，一个 sprite 创建并编码完之后，就很少会被改动了，也不会受进行中的网站维护的影响。假如你感觉 sprite 维护不是个问题的话，那么也许使用大型 sprite 是最好的选择。

不是所有图片都是背景

另一个不提倡滥用 CSS sprite 的理由是这会导致开发人员错误地使用背景图片。有经验的开发人员会在项目中考虑可访问性问题，他们明白并不是每个图片都是背景。背景图片应该留给按钮以及用来装饰元素，而用来传达重要信息的图像应该内联在 XHTML 中。

Amazon 正确是使用了内联图像元素和装饰用的背景。

错误得使用 Sprites 影响可访问性

一些刚入门的开发人员会为了节省 HTTP 请求数(这是使用 CSS Sprite 一直强调的好处)而把所有的图片都当背景图片来处理 – 甚至是那些传达重要信息的图片。结果会导致一个缺乏可访问性的网站，也会降低 HTML 中 title 和 alt 的潜在益处。

因此，CSS sprite 本身没错，而且也不会引发可访问性问题(事实上，正确得使用会提高可访问性)。但是不分对错得过度使用 sprite 会阻碍具有可访问性和生产率方面的网页建设进程。

HTTP 请求数又如何？

许多人会据理力争，改善网站性能最重要的部分就是减少 HTTP 请求数。也要知道一项研究表明一个网站日常的访问者中 40-60% 比例都是没有浏览器缓存的。这是否足以说明应该在所有情况下使用大型 sprites 呢？或许是这样。尤其是考虑到用户的首次来访对一个网站的重要性。

Firefox 的 YSlow 插件显示 HTTP 请求数

以往的浏览器一般只允许 2 个并发 HTTP 连接，3.0 版本以来的 Firefox 和 IE8 默认允许 6 个并发 HTTP 连接。这意味着每台服务器有 6 个并发连接。引用 Steve Souders 的话：

“明白这是服务器的基础是很重要的。使用多个域名，如 1.mydomain.com, 2.mydomain.com, 3.mydomain.com, 等等，使开发人员可以完全利用服务器连接数。在所有域名是同一 IP 地址的 CNAME 时依然有效。”

因此，或许在按钮状态之外使用 CSS sprites 也是有益的，在未来，随着网络连接速度的加快和新版浏览器的性能提升，使用大型 sprites 所带来的好处将会变得不值一提。

那些 Sprites 生成器呢？

另一个喜爱大型 sprite 的理由是可以利用一些 sprite 生成器来简单得生成 sprite。对此类工具的详细讨论和评测不在本文讨论范围。但是从作者对此类工具的研究来看，帮助非常有限，并且维护这些 sprites 一样需要可观的工作量，这也是需要和收益权衡的。

有些工具，例如来自 Fondue 项目的这个，提供输出 CSS 选项。Steve Souders’ 的工具 SpriteMe 是另一个提供 CSS 编码选项的。SpriteMe 会把现有的网站背景图片转换成单张 sprite 图片（我之前提到的“大型” sprite）并提供下载以供编码入页面之中。然而这些工具只是有助于创建 sprite，并不能在维护方面提供多少帮助。Souder 的工具貌似对重新设计或布局的网站无效，而且只对那些现有的没有使用 sprite 方法的网站有用。

可以改进现有的工具，而且未来也会有新的工具出现。但是，鉴于以上提到的这些缺点，是否还存在这种可能，就是开发人员依然把精力集中在有限的所得上？

关注多个性能提升点

上面提到，HTTP 请求数是提升网站性能需要考虑的一个非常重要的因素。但是有别的方法可以减少连接数，包括合并脚本和样式表，使用远程库文件（即使用 Google 或者 Yahoo！提供的库文件托管）。

除了 HTTP 请求数之外还有很多开发人员可以关注的用于提升网站性能的因素。包括服务器启用 Gzip，正确的放置外链脚本，优化 CSS 语法，压缩较大的 JavaScript 文件，提升 Ajax 性能，避免使用已知的会引起性能问题的 JavaScript 语法，等等。

YSlow 显示了 HTTP 请求数之外可以提升网站性能的因素

如果开发人员花点时间来考虑下所有可以提升网站性能的因素，再权衡下利弊，也许就有较好的理由可以避免滥用 CSS sprite 了，并且会把精力放在那些物有所值的方面。

总结

请不要误解我所说的。许多顶级的 blogger 和开发人员已经称颂 sprite 的好处很多年了，最近几年又把这些意见推广到使用大型 sprite 上来了 – 因此应该认真得考虑下这些观点。但是，这种有着完善的体制和系统，使得网站维护任务简化并流水化的公司，并不是所有人都能进去的。大多数人都是独立工作，或者接受别人创建的项目。这类情况下，大型的 sprite 会导致得不偿失的麻烦。

糖伴西红柿的总结

标题有点醒目 :) 原标题的规矩翻译为 CSS Sprites：有用的技术还是潜在的麻烦？

关于 CSS Sprite，在 Web 标准交流会 第二期的时候讨论过。其实 CSS Sprite 是很有用处的。但是前提是不要超出一个度的限制。基本上很多问题最终都会归于如何适度地使用的问题。老话说：过犹不及，其实还是很有道理的。

对于减少 HTTP 请求数问题，可以稍作妥协，把图片分类，尽量把内容固定、后期不会有太多变动的图归入一个 sprite 中，例如一些 icon 。那些会经常改动的图片归入一类，分成几组 sprite。对于设计花哨而生命周期很短的专题来说，真得，花费在拼图上的时间和经历实在是有点浪费了。

关于老外的文章，我现在觉得有些絮叨了。或许很多人也会有这个感觉。其实应该反思下，据说日本有专门的小册子来教人做一些非常基础的东西，内容步骤细致到令人发指得地步。基础的东西大多人会不屑一顾，觉得别人都谈论奇技淫巧、高级应用了，我还在搞这些基础，多丢人啊。

基础的东西其实没那么简单的，有谁能真得掌握了这些看上去简单的基础呢？看一下这个基础问题你真的了解HTML吗?

曾经有一个高手送我一本书，他写了 ”Back to basic“ 送我，我在这里送给大家，希望大家都能踏踏实实地努力进步。

以下文档描述了应用在 Mozilla UI 中优化 CSS 文件的规则。第一部分是对于 Mozilla 样式系统分类规则的一般性讨论。在了解这个系统的基础上，后续部分包含了一些指南，书写可以利用这个样式系统实践优点的样式的指南。

样式系统如何分类规则

样式系统把规则分为四大类。理解这些类是很重要的，因为对于规则的匹配来说他们是首先要考虑的。之后的段落中会使用“主选择符”这个说法。主选择符是指选择符最右边的部分(最终要匹配的那个元素，而不是它的祖先元素)。例如，在以下规则中：

a img, div > p, h1 + [title] {}

主选择符是 “img”, “p”, 和 “[title]“。

ID 规则

ID 选择符作为主选择符的规则。

例如：

• button#backButton { } /* ID 类别的规则 */
• #urlBar[type="autocomplete"] { } /* ID 类别的规则 */
• treeitem > treerow > treecell#myCell:active { } /* ID 类别的规则 */

Class 规则

如果一条规则有一个指定的 class 作为主选择符，就被归入此类。

例如：

• button.toolbarButton { } /* 基于 class 的规则 */
• .fancyText { } /* 基于 class 的规则 */
• menuitem > .menu-left[checked="true"] { } /* 基于 class 的规则 */

Tag 规则

如果主选择符不是 ID 或者 class，那么下一个类很可能就是 tag 分类。如果一条规则指定 tag 为主选择符，就被归入此类。

例如：

• td { } /* 基于 tag 的规则 */
• treeitem > treerow { } /* 基于 tag 的规则 */
• input[type="checkbox"] { } /* 基于 tag 的规则 */

全局规则

除以上分类之外都归入此类。

例如：

• [hidden="true"] { } /* 全局规则 */
• *{} /* 全局规则 */
• tree > [collapsed="true"] { } /* 全局规则 */

样式系统如何匹配规则

样式系统从最右边的选择符开始向左侧移动来匹配一条规则。样式系统会一直向左匹配选择符直到规则匹配完毕或者由于出错停止匹配。

对于规则分类的第一步发生在主选择符类别基础上。这个分类的目的是把那些不需要浪费时间匹配的规则过滤出来。这是显著提升性能的重点。对于一个给定的需要匹配的元素，规则越少，样式的渲染越快。例如，元素有一个 ID，那么只有和元素 ID 匹配的 ID 规则会被检索。只有和元素的 class 匹配的 class 规则会被检索。只有和 tag 匹配的 tag 规则会被检索。全局规则总是会被检索。

高效 CSS 指南

避免全局规则

确保规则不以全局分类结束

不要给 ID 分类规则指定标签名或者 class

如果有一条样式规则是以 ID 选择符为主选择符的，就别再画蛇添足的加上标签名了。ID 都是唯一的，因此加上标签名反而会无谓地拖慢匹配过程。(当有不同元素使用同一类名，而又需要动态地改变其中一个元素的类名来针对不同情况应用不同样式时是个例外。)

• BAD – button#backButton { }
• BAD – .menu-left#newMenuIcon { }
• GOOD – #backButton { }
• GOOD – #newMenuIcon { }

不要给 class 分类规则指定标签名

和以上规则类似，所有的类名也是唯一的。标签和类名连缀的写法是一个惯例(但是，如果设计的变更使得需要改变标签就会有灵活性的问题，因为也需要改变 class — 最好选用具有严格语义的名字，这种灵活性也是分离样式表的目标之一)。

• BAD – treecell.indented { }
• GOOD – .treecell-indented { }
• BEST – .hierarchy-deep { }

尽量把规则应用到最明确的类上。

拖慢系统最大的一个原因是有太多的 tag 分类规则了。通过给元素增加类名，可以把这些 tag 类里的规则分一部分去class 分类，就可以不需要浪费时间来试图给一个标签匹配那么多的的规则了。

• BAD – treeitem[mailfolder="true"] > treerow > treecell { }
• GOOD – .treecell-mailfolder { }

避免后代选择符

CSS 中，后代选择符(descendant)^[注1]的耗能高的可怕，尤其是选择符的规则是在 tag 或者全局分类中。子选择符(child selector)则经常是真正所需。如果没有主题模块所有者的明确允许，UI CSS 中禁止使用后代选择符。

• BAD – treehead treerow treecell { }
• BETTER, BUT STILL BAD (see next guideline) – treehead > treerow > treecell { }

Tag 类规则中最好不要包含后代选择符

避免使用具有 tag 类规则的后代选择符。这会明显地增加匹配时间（尤其是这些规则会被多次匹配时）。

• BAD – treehead > treerow > treecell { }
• BEST – .treecell-header { }

小心子选择符的使用

要小心使用子代选择符。如果有别的方式可以不用，就不要用子选择符。尤其是子选择符被大量使用在 RDF 树和类似的菜单中时。

• BAD – treeitem[IsImapServer="true"] > treerow > .tree-folderpane-icon { }

要注意模版中来自 RDF 的属性是可以复制的！可以利用这一点把 RDF 属性复制到需要改变那个属性的子元素上。

• GOOD – .tree-folderpane-icon[IsImapServer="true"] { }

倚赖继承

了解并使用那些可以继承的属性。XUL widgetry^[注2] 已经明确设置了，因此可以把 list-style-image 或者 font 规则应用到父级标签上，它将渗透进匿名内容。因此就不需要浪费时间为那些匿名内容写规则了。

• BAD – #bookmarkMenuItem > .menu-left { list-style-image: url(blah); }
• GOOD – #bookmarkMenuItem { list-style-image: url(blah); }

上例中，样式化匿名内容的需求（没有理解 list-style-image 可以继承）导致了一条 class 类规则。其实这条规则应该属于最明确的一类 — ID 类规则。

要记住，尤其是那些匿名内容，它们都有同样的 class。上面那个不好的例子导致需要检查每个菜单的图标是否包含在 bookmarks 菜单项中。这是非常可怕的高昂消耗（有很多菜单）；除 bookmarks 菜单之外，这条规则不应该被其他任何菜单想检查。

使用 -moz-image-region

把一堆图片放到一个单独的图片文件中，并用 -moz-image-region^[注3] 选中会有显著的性能提升。()

注1: 后代选择符(descendant selector) 子选择符(child selector) 是有区别的。单从字面来讲，后代选择符，顾名思义包括儿子、孙子、重孙子等所有后代; 子选择符只是指儿子，就不管那帮孙子了。

注2: XUL widgetry 不清楚是啥。

注3: 貌似想法和现在说的 CSS sprites 方法差不多，要知道这可是十年前(2000年)的文章啊。 – 糖伴西红柿

.clearfix:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
.clearfix { display: inline-table; }
/* Hides from IE-mac \*/
* html .clearfix { height: 1%; }
.clearfix { display: block; }
/* End hide from IE-mac */

说明：

• *对大多数符合标准的浏览器应用第一个声明块，目的是创建一个隐形的
  内容为空的块来为目标元素清除浮动。
• *第二条为clearfix应用 inline-table 显示属性，仅仅针对IE/Mac。
  *利用 * / 对 IE/Mac 隐藏一些规则：
• * height:1% 用来触发 IE6 下的haslayout。
• *重新对 IE/Mac 外的IE应用 block 显示属性。
• *最后一行用于结束针对 IE/Mac 的hack。

由于此方法针对的浏览器或成为历史（尤其是Mac下的IE5 ），或正在靠近
标准的路上，这个方法就不再那么与时俱进了。

抛掉对 IE/Mac 的支持之后，新的清除浮动方法：

/* new clearfix */
.clearfix:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
* html .clearfix             { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

说明：

IE6 和 IE7 都不支持 :after 这个伪类，因此需要后面两条来触发IE6/7的haslayout，以清除浮动。幸运的是IE8支持 :after 伪类。因此只需要针对IE6/7的hack了。

糖伴西红柿说：
Jeff Starr 在这里针对IE6/7用了两条语句来触发haslayout。我在想作者为什么不直接用 * 来直接对 IE6/7 同时应用 zoom:1 或者直接就写成：

.clearfix:after {
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
}
.clearfix{*zoom:1;}

以我目前的浅薄认知来讲，以上写法应该也可以直接达到同样效果。关于这个地方，在文章的评论里也有些讨论，我希望再听听大家的高见。

我平时都是用 overflow:hidden 来清除浮动的，因为够简单粗暴。但是 overflow 有时候也不太适用：

父级元素使用 overflow:hidden 时，如果其子元素定位到部分或全部在父元素之外，父元素就会对超出其外的子元素部分进行裁剪。

对 css3 来说，也会 overflow:hidden 也会对一些属性产生影响。
例如 box-shadow, 当父元素使用 overflow:hidden 属性时，box-shadow 会被裁剪。

其他可能被影响的元素如 text-shadow 和 transform。可以参考 Andy Ford 的 demo

对于那些不愿意再给标签添加额外的 clearfix 类来清除浮动的人来说，直接将需要清除浮动的元素添加进清除浮动代码块这个组也是一个办法。

.group:after,
#content:after,
#sidebar:after,
#some .other .thing:after
{
visibility: hidden;
display: block;
font-size: 0;
content: " ";
clear: both;
height: 0;
zoom:1;
}

这种情况下，html 和 css 文件就像一个跷跷板的两头。html 代码倒是整洁了，css 代码却出现了一定的繁冗。而且一旦专题页面过长，或者在项目中使用，用这个清除组的方式反而会不胜其扰。

归结下来，还是得看个人、项目的权衡选择.虽然我一直用简单粗暴的overflow:hidden，但是现在更倾向于使用 clearfix，感觉这种一体化的东西更靠谱，能避免偶尔对 zoom 的遗忘。

成熟的东西稳定性好，但是会比较复杂、厚重;简单的灵活性好，但是过于零散、随意，没有组织性，还没那么稳定.权衡决定到底要使用那种方法，有时候反而比问题本身还让人头疼.

我个人的想法是没有好与坏的区别，只有合适不合适的区别。但是我们一直都受困于所受的教育，什么问题都有标准答案，非对即错，非好即坏。经常可见对一些工具的讨论，都是奔着争出个谁好谁坏而去的，例如 jQuery mootools YUI.相比起到底是好谁坏，我们还是最好赶紧转变思想，摒弃”一刀切”的思想吧。

最后，关于为什么要采用一下这种复杂方式来针对IE6/7，而不采用其他稍微简洁的方式，还希望大家给我指点下迷津。

* html .clearfix             { zoom: 1; } /* IE6 */
*:first-child+html .clearfix { zoom: 1; } /* IE7 */

Reference:

• [1].Jeff Starr，The New Clearfix Method， December 6, 2009
• [2].Andy Ford, Saying Goodbye to the overflow: hidden Clearing Hack, December 10th, 2009

首先要说明的是，这个标题有点标题党的意思，这个 bug 也存在于 IE8 下，在 IE6 和 IE7 下正常。之前写过两篇关于 IE bug 的文章，这里特意用了 Firefox bug 作为标题，是为了给自己找点心里安慰，省得总是埋怨 IE :)。

关于 inline-block，可以参考之前的一篇文章 跨浏览器的inline-block

这个 bug 是“痛在远方”同学碰到的，确实很诡异啊，貌似对标准支持越好的浏览器才会有这个问题。本文来自前端观察，转载请以链接形式注明出处。

如下图：

在 Firefox 下，inline/inline-block 的元素直接会有莫名的几像素(貌似是6px)的空隙。这个 bug 比较难发现，因为为了美观，一般的这种设计，inline/inline-block 的元素直接都会有一定的间距，再加上目前的浏览器对 inline-block 这个属性的支持并不是很好，这个属性应用的也不是很频繁。由跨浏览器的inline-block来看，要对浏览器做不少hack，代码量以及方便性上不如直接使用浮动。因此这个 bug 的影响其实不大。本文来自前端观察，转载请以链接形式注明出处。

要解决这个 bug，貌似目前没有什么好的方法，只能改变代码的缩进，把换行去掉，整个代码写入一行。

具体可以参见 demo。

本文来自前端观察，转载请以链接形式注明出处。

首先，从字面上来理解，dashed 和 dotted 都是指“虚线”，他们的不同在于：

dashed：来自 dash（破折号），由 dash 组成的虚线
dotted：来自 dot （点），由 dot 组成的虚线，也称点线

这里多说几句废话，其实参看下 demo，就能从视觉上获得更直观的感受了。
下面再说说相关的 bug 吧，当然了，这些 bug 再一次只是光荣地出现在了 IE 下，此处涉及到 IE6 和 IE7。本文来自前端观察，转载请以链接形式注明版权。

Bug1: 在 IE6 下，1px 宽的 dotted 表现的和 dashed 一样。当宽度大于 1px 时，表现正常。

Bug2:在 IE7 下，当 4 条边的宽度是 1px 和 其它任意数值共存时，1px 的 dotted 表现的和 dashed 一样。4 条边的宽度全为 1px，或者为其它不是 1px 的不同值时不会出现这个 bug。

Bug3:另外，IE6 下，1px 的 dotted 或者 1px 的 dashed 边框，在拖动页面时，有时候边框会连成实线，有时候会出现缺口。

要解决这些 bug，要么直接就不用 dotted 而直接用 dashed；要么用图片代替；要么用额外标签和代码来解决。本文来自前端观察，转载请以链接形式注明版权。

鉴于只有在边框宽度为 1px 时才会出现这些 bug，可以设置外包围标签的边框宽度为 2px，通过增加一个内标签，设置其为 1px 的内容背景色边框，再通过设置 margin-top/right/bottom/left: -1px; 来盖掉外包围标签的 1px 边框，从视觉上实现正常效果。很啰嗦，很讨厌，很无奈。

.b6 {
border: 2px dotted #000;
padding-top: 0;
}
.b6 .inner {
border: 1px solid #9c9c9c;
width: 100%;
height: 100%;
margin: -1px;
position: relative;
z-index: 100;
}

详情请参考 demo 本文来自前端观察，转载请以链接形式注明版权。

前两天碰到了这个奇怪的问题：

绝对定位的元素，紧邻着两个浮动元素。Firefox 中一切正常，IE6 中绝对定位元素消失了。本文来自前端观察，转载请以链接形式注明出处。

解决方法：只要别让绝对定位元素紧邻浮动元素就可以了。比如可以在绝对定位元素后面加个空元素。当然，这个空元素是毫无意义的，但是，在 IE 面前，又能怎么样呢？

经过实验，我发现，只要浮动元素的宽度不填满父元素，绝对定位元素就能正常显示，一旦浮动元素的宽度填满父元素，绝对定位元素就会消失。而且，看来，父元素宽度是这种情况发生的临界点。本文来自前端观察，转载请以链接形式注明出处。

另外，这个 demo 里面也存在 IE6 的另一个经典 bug : 由注释产生的表现不同。(唉，bug 都成经典了，IE 无敌啊。— 糖伴西红柿)本文来自前端观察，转载请以链接形式注明出处。

请看上面的图中，上面那块，就是有注释的，下面那块是去掉注释的，可以明显的看到底部的白色空白高度是不同的。

具体效果可参见 demo。

译文链接：css 背景全攻略

转载请保留版权以及链接

——————————————————————————————

背景(background)是css中一个重要的的部分，也是需要知道的css的基础知识之一。这篇文章将会涉及css背景(background)的基本用法，包括诸如 background-attachment 等的属性，也会介绍一些有关背景(background)的常用技巧，以及 css3 中的 背景(background)(包含4个新的背景(background)属性)。

css2 中的背景(background)

概述

CSS2 中有5个主要的背景(background)属性，它们是：

* background-color: 指定填充背景的颜色。

* background-image: 引用图片作为背景。

* background-position: 指定元素背景图片的位置。

* background-repeat: 决定是否重复背景图片。

* background-attachment: 决定背景图是否随页面滚动。

这些属性可以全部合并为一个缩写属性: background。需要注意的一个要点是背景占据元素的所有内容区域，包括 padding 和 border，但是不包括元素的 margin。它在 Firefox, Safari ,Opera 以及 IE8 中工作正常，但是 IE6 和 IE7 中，background 没把 border 计算在内。

基本属性

背景色(background-color)

background-color 属性用纯色来填充背景。有许多方式指定这个颜色，以下方式都得到相同的结果。

background-color: blue;
background-color: rgb(0, 0, 255);
background-color: #0000ff;

background-color 也可被设置为透明（transparent），这会使得其下的元素可见。

背景图(background-image)

background-image 属性允许指定一个图片展示在背景中。可以和 background-color 连用，因此如果图片不重复地话，图片覆盖不到地地方都会被背景色填充。代码很简单，只需要记住，路径是相对于样式表的，因此以下的代码中，图片和样式表是在同一个目录中的。

background-image: url(image.jpg);

但是如果图片在一个名为 images 的子目录中，就应该是：

background-image: url(images/image.jpg);

糖伴西红柿：使用 ../ 表示上一级目录，比如 background-image: url(../images/image.jpg); 表示图片位于样式表的上级目录中的 images 子目录中。有点绕，不过这个大家应该都知道了，我就不详说了。前端观察 版权所有，转载请保留链接。

背景平铺(background-repeat)

设置背景图片时，默认把图片在水平和垂直方向平铺以铺满整个元素。这也许是你需要的，但是有时会希望图片只出现一次，或者只在一个方向平铺。以下为可能的设置值和结果：

background-repeat: repeat; /* 默认值，在水平和垂直方向平铺 */
background-repeat: no-repeat; /* 不平铺。图片只展示一次。 */
background-repeat: repeat-x; /* 水平方向平铺(沿 x 轴) */
background-repeat: repeat-y; /* 垂直方向平铺(沿 y 轴) */
background-repeat: inherit; /* 继承父元素的 background-repeat 属性*/

背景定位(background-position)

background-position 属性用来控制背景图片在元素中的位置。技巧是，实际上指定的是图片左上角相对于元素左上角的位置。
下面的例子中，设置了一个背景图片并且用 background-position 属性来控制它的位置，同时也设置了 background-repeat 为 no-repeat。计量单位是像素。第一个数字表示 x 轴(水平)位置，第二个是 y 轴(垂直) 位置。

/* 例 1: 默认值 */
background-position: 0 0; /* 元素的左上角 */
 
/* 例 2: 把图片向右移动 */
background-position: 75px 0;
 
/* 例 3: 把图片向左移动 */
background-position: -75px 0;
 
/* 例 4: 把图片向下移动 */
background-position: 0 100px;

background-position 属性可以用其它数值，关键词和百分比来指定，这比较有用，尤其是在元素尺寸不是用像素设置时。

关键词是不用解释的。x 轴上：

• * left
• * center
• * right

y 轴上:

• * top
• * center
• * bottom

顺序方面和使用像素值时的顺序几乎一样，首先是 x 轴，其次是 y 轴，像这样：

background-position: top right;

使用百分数时也类似。需要主要的是，使用百分数时，浏览器是以元素的百分比数值来设置图片的位置的。看例子就好理解了。假设设定如下：

background-position: 100% 50%;

This goes 100% of the way across the image (i.e. the very right-hand edge) and 100% of the way across the element (remember, the starting point is always the top-left corner), and the two line up there. It then goes 50% of the way down the image and 50% of the way down the element to line up there. The result is that the image is aligned to the right of the element and exactly half-way down it.

糖伴西红柿：这一段没想到合适的翻译，保留原文，意译。前端观察 版权所有，转载请保留链接。

update: 感谢天涯的指教，这段搞明白了。使用百分数定位时，其实是将背景图片的百分比指定的位置和元素的百分比位置对齐。也就是说，百分数定位是改变了背景图和元素的对齐基点。不再像使用像素和关键词定位时，使用背景图和元素的左上角为对齐基点。例如上例的 background-position: 100% 50%; 就是将背景图片的 100%(right) 50%(center) 这个点，和元素的 100%(right) 50%(center) 这个点对齐。

这再一次说明了，我们一直认为已经掌握的简单的东西，其实还有我们有限的认知之外的知识。

注意原点总是左上角，最终的效果是笑脸图片被定位在元素的最右边，离元素顶部是元素的一半，效果和 background-position: right center; 一样。

背景附着

background-attachment 属性决定用户滚动页面时图片的状态。三个可用属性为 scroll(滚动)，fixed(固定) 和 inherit(继承)。inherit 单纯地指定元素继承他的父元素的 background-attachment 属性。

为了正确地理解 background-attachment，首先需要明白页面(page)和视口(view port)是如何协作地。视口(view port)是浏览器显示网页的部分(就是去掉工具栏的浏览器)。视口(view port)的位置固定，不变动。

当向下滚动网页时，视口(view port)是不动的，而页面的内容向上滚动。看起来貌似视口(view port)向页面下方滚动了。如果设置 background-attachment: scroll，就设置了当元素滚动时，元素背景也必需随着滚动。简而言之，背景是紧贴元素的。这是 background-attachment 默认值。

用一个例子来更清楚地描述下：

background-image: url(test-image.jpg);
 
background-position: 0 0;
background-repeat: no-repeat;
background-attachment: scroll;

当向下滚动页面时，背景向上滚动直至消失。

但是当设置 background-attachment 为 fixed 时，当页面向下滚动时，背景要待在它原来的位置(相对于浏览器来说)。也就是不随元素滚动。

用另一个例子描述下：

background-image: url(test-image.jpg);
background-position: 0 100%;
background-repeat: no-repeat;
background-attachment: fixed;

页面已经向下滚动了，但是图像仍然保持可见。

需要重视的一点是背景图只能出现在它父元素能达到的区域。即使图片是相对于视口(view port)定位地，如果它的父元素不可见，图片就会消失。参见下面的例子。此例中，图片位于视口(view port)的左下方，但是只有元素内的图片部分是可见的。

background-image: url(test-image.jpg);
background-position: 0 100%;
background-repeat: no-repeat;
background-attachment: fixed;

因为图片开始在元素之外，一部分图片被切除了。

背景的简写属性

可以把背景的各个属性合为一行，而不用每次都单独把他们写出来。格式如下：

background: <color> <image> <position> <attachment> <repeat>

例如，下面的声明

background-color: transparent;
background-image: url(image.jpg);
background-position: 50% 0 ;
background-attachment: scroll;
background-repeat: repeat-y;

可以合为单独一行：

background: transparent url(image.jpg) 50% 0 scroll repeat-y;

而且不需要指定每一个值。如果省略值地话，就使用属性地默认值。例如，上面那行和下面这个效果一样：

background: url(image.jpg) 50% 0 repeat-y;

背景的一般用法

除了可以用来使元素更加优雅这类显然的用法之外，背景也可以用于其它的目的。

仿栏

当使用 css 的 float 属性来定位布局元素时，要确保两栏或多栏有相同的长度是比较困难的。如果长度不同，其中一栏的背景会比另外的短，这会破坏整个设计。

仿栏是个非常简单的背景技巧，这个技巧最早发表在A List Apart 。思路很简单：不再给每列单独设置背景，而是给各列的父元素设置一个背景图。所有栏的设计都包含在这张图片之中。

文本替换

在网页上，对于字体的选择是相当有限的。可以使用 sIFR 之类的工具来定制字体，但是这需要用户启用 JavaScript 。一个适用于任意浏览器的简单方法是，用想用的字体来做一张文本图片，并用这张图片作为背景。这样，文本依然出现在文档标记中以供搜索引擎检索和屏幕浏览器识别，但是在浏览器中就会显示首选的字体。

例如，HTML 标记可能是这样的：

<h3>Blogroll</h3>

假如有一个 200 乘 75 的图片，上面有更好看的字体，就可以用如下方式来替换文本：

h3.blogroll {
width: 200px;
height: 75px; /* So that the element will show the whole image. */
background:url(blogroll-text.jpg) 0 0 no-repeat; /* Sets the background image */
text-indent: -9999px; /* Hides the regular text by moving it 9999 pixels to the left */
}

简单的圆点

无需列表中的圆点看起来很难看。不用再处理所有不同的 list-style 属性，只需要简单地把他们隐藏并用背景图代替就可以了。因为图片可以随意选择，这些圆点就可以看起来更漂亮。

下面，我们把一个无需列表改造成有圆滑圆点的：

ul {
list-style: none; /* Removes default bullets. */
}
 
ul li {
padding-left: 40px; /* Indents list items, leaving room for background image on the left. */
background: url(bulletpoint.jpg) 0 0 no-repeat;
}

CSS3 中的背景

CSS3 中的背景有较多改进。最显著的是多背景图片的选项，同时也增加了4个新属性。

多背景

CSS3 中，可以对一个元素应用一个或多个图片作为背景。代码和 css2 中的一样，只需要用逗号来区别各个图片。第一个声明的图片定位在元素顶部，其它的图片按序在其下排列，例如：

background-image: url(top-image.jpg), url(middle-image.jpg), url(bottom-image.jpg);

新属性：背景修剪(background-clip)

这又把我们带回了文章开始讨论的那个关于边框内图片显示的话题。它被描述为“背景描绘区”。

background-clip 属性用来增强背景显示位置的控制能力。可能的值为：

* background-clip: border-box;
背景显示在边框内。
* background-clip: padding-box;
背景显示在内补白(padding)内，而不是边框内。
* background-clip: content-box;
只在内容内显示背景，而不是内补白(padding)和边框内。
* background-clip: no-clip;
默认值，和 border-box 一样。

新属性：背景原点(background-origin)

这个属性和 background-position 结合起来使用。可以从边框，内补白或者内容盒子开始计算 background-position (类似于 background-clip)。

* background-origin: border-box;
以边框为原点开始计算 background-position.
* background-origin: padding-box;
以内补白为原点开始计算 background-position
* background-origin: content-box;
以内容盒子为原点开始计算 background-position
对于 background-clip 和 background-origin 不同的一个解释参看 CSS3.info

新属性： 背景尺寸(background-size)

background-size 用来调整背景图的大小。有好几个可能值：

* background-size: contain;
缩小图片来适应元素的尺寸(保持像素的长宽比)
* background-size: cover;
扩展图片来填满元素(保持像素的长宽比)
* background-size: 100px 100px;
调整图片到指定大小
* background-size: 50% 100%;
调整图片到指定大小。百分比是相对于包含元素的尺寸的。

可以看一下 CSS3规则 网站上的几个例子。

新属性：(background-break)

CSS3 中，元素可以被分成几个独立的盒子(例如 使内联元素 span 跨越多行)。background-break 属性用来控制背景怎样在这些不同的盒子中显示。

可能值为：

* Background-break: continuous;
默认值。忽略盒之间的距离(也就是像元素没有分成多个盒子，依然是一个整体一样)
* Background-break: bounding-box;
把盒之间的距离计算在内
* Background-break: each-box;
为每个盒子单独重绘背景

背景色(background-color)的改进

background-color 在 css3 中有了稍许改进。除了设置背景颜色之外，如果元素底层的背景图不可用，还可以设置一个“回退色”。

通过在回退色之前增加一个斜杠(/)来实现，例如：

background-color: green / blue;

此例中，背景色应该是绿色(green)。然而，如果底层背景图不能使用的话，背景色就是蓝色而不是绿色。如果在斜杠前不指定颜色，默认为透明(transparent)。

背景平铺(background-repeat)的改进

CSS2中当图片平铺时，会被元素在末端截断。CSS3 引入了两个属性来修正这个问题:

* space: 应用同等数量的空白到图片之间，直到填满整个元素
* round: 缩小图片直到正好平铺满元素
关于 background-repeat: space; 的一个例子，可以在 CSS3 规则网站看到。

背景附着(background-attachment)的改进

background-attachment 属性增加了一个新值：local。这是用来配合可以滚动的元素的(设置为 overflow: scroll; 的元素)。当 background-attachment 设置为滚动(scroll)时，背景图不会随元素内容的滚动而滚动。

设置为 background-attachment :local; 时，背景图会随内容的滚动而滚动。

总结

总结一下，css 中关于背景有许多需要知道的知识。但是一旦把这些知识融会贯通了，这些技术和命名约定就变得非常有意义而且很快就会成为潜意识行为了。

如果刚接触 css，主要不断联系就可以较快地掌握背景的要点了。如果是老手，我希望你可以和我一样期待 css3 。

关于作者

Michael Martin 的文章大多涉及网页设计，WordPress 并为 Pro Blog Design 工作。可以查看更多关于博客设计的文章或者在 twitter 上关注他。

糖伴西红柿：一看到这么长篇大论的也头晕，花了好几天的时间折腾这篇文章。全是基础的只是，没有什么花哨的，但是我觉得最基础的也是最重要的。

鉴于好多网站都会转载别人的文章，当然了，好的文章我们也会转载，不过有些人直接把别人辛辛苦苦的劳动付出拿来当自己的东西。

这些人真的很无耻，这个大环境也真的很悲哀，没人愿意踏踏实实地做事。这就是为什么我们总是翻译国外的文章，而不是把咱们的文章翻译成外语让外国人看的根本所在。

可悲啊。

什么是浮动？

浮动是 css 的定位属性。我们可以看一下印刷设计来了解它的起源和作用。印刷布局中，文本可以按照需要围绕图片。一般把这种方式称为“文本环绕”。
这是一个例子：

在排版软件里面，存放文字的盒子可以被设置为允许图文混排，或者无视它。无视图文混排将会允许文字出现在图片的上面，就像它甚至不会在那里一样。这就是图片是否是页面流的一部分的区别。网页设计与此非常类似。

在网页设计中，应用了CSS的float属性的页面元素就像在印刷布局里面的被文字包围的图片一样。浮动的元素仍然是网页流的一部分。这与使用绝对定位的页面元素相比是一个明显的不同。绝对定位的页面元素被从网页流里面移除了，就像印刷布局里面的文本框被设置为无视页面环绕一样。绝对定位的元素不会影响其它元素，其它元素也不会影响它，无论它是否和其它元素挨着。

像这样在一个元素上用CSS设置浮动：

#sidebar { float: right; }

fload属性有四个可用的值：Left 和Right 分别浮动元素到各自的方向，None (默认的) 使元素不浮动，Inherit 将会从父级元素获取float值。

浮动的用处

除了简单的在图片周围包围文字，浮动可用于创建全部网页布局。

浮动对小型的布局同样有用。例如页面中的这个小区域。如果我们在我们的小头像图片上使用浮动，当调整图片大小的时候，盒子里面的文字也将自动调整位置：

同样的布局可以通过在外容器使用相对定位，然后在头像上使用绝对定位来实现。这种方式中，文本不会受头像图片大小的影响，不会随头像图片的大小而有相应变化。

清除浮动

清除(clear)是浮动(float)的相关属性.一个设置了清除浮动的元素不会如浮动所设置的一样，向上移动到浮动元素的边界，而是会忽视浮动向下移动。如下，一图顶千言。

上例中，侧栏向右浮动，并且短于主内容区域。页脚(footer)于是按浮动所要求的向上跳到了可能的空间。要解决这个问题，可以在页脚(footer)上清除浮动，以使页脚(footer)待在浮动元素的下面。

#footer { clear: both; }

清除(clear)也有4个可能值。最常用的是 both，清楚左右两边的浮动。left 和 right 只能清楚一个方向的浮动。none 是默认值，只在需要移除已指定的清除值时用到。inherit 应该时第五个值，不过很奇怪的是 IE 不支持(这个不奇怪吧，IE 从来都这么特立独行吧 －糖伴西红柿注)。只清除左边或右边的浮动，实际中很少见，不过绝对有他们的用处。

伟大的塌陷

使用浮动(float)的一个比较疑惑的事情是他们怎么影响包含他们的父元素的。如果父元素只包含浮动元素，那么它的高度就会塌缩为零。如果父元素不包含任何的可见背景，这个问题会很难被注意到，但是这是一个很重要的问题。

塌陷的直观对立面更不好，看看下面的情况：

当上面的块级元素自动扩展以适应浮动元素时，段落间的文本流中会出现非自然的空白换行，而且没有有效的方法来修正这个问题。对于这种情况，设计师的抱怨会更甚于对塌陷的抱怨（没理解，不是设计完成之后才会进行页面编码吗？－ 糖伴西红柿）。

为了防止怪异的布局和跨浏览器的问题，塌陷问题几乎总是被要处理的。我们在容器中的浮动元素之后，容器结束之前来清除浮动。

清除浮动的技术

如果你很明确的知道接下来的元素会是什么，可以使用 clear:both; 来清除浮动。这个方法很不错，它不需要 hack，不添加额外的元素也使得它有良好的语义性。当然事情并不是都可以这样解决的，工具箱中还是需要另外几个清除浮动的工具。

• 空div方法从字面来看，是一个空的 div。
  。有时可能会用
  或者一些其他元素，但是 div 是最常用的，因为它没有浏览器默认样式；没有特殊功能，而且一般不会被 css 样式化。这个方法因为只是为了表现，对页面没有上下文涵义而被纯语义论者嘲笑。诚然，从严格的角度来说他们是对的，但是这个方法有效而且没有任何伤害。
• overflow 方法在父元素上设置 overflow 这个 css 属性。如果父元素的这个属性设置为 auto 或者 hidden，父元素就会扩展以包含浮动。这个方法有着较好的语义性，因为他不需要额外元素。但是，如果需要增加一个新的 div 来使用这个方法，其实就和空 div 方法一样没有语义了。而且要记住，overflow 属性不是为了清除浮动而定义的。要小心不要覆盖住内容或者触发了不需要的滚动条。
• 简单清除方法使用了一个聪明的 css 伪选择符(:after)来清除浮动。比起在父元素上设置 overflow，只需要给它增加一个额外的类似于”clearfix”的类。这个类使用如下 css:

  			.clearfix:after {
     				content: ".";
     				visibility: hidden;
     				display: block;
     				height: 0;
     				clear: both;
  			}

  这会在清除浮动的父元素之后应用一点看不见的内容。这不是全部内容，还需要一些额外的代码来适应那些老旧的浏览器。

不同的情况需要不同的浮动清除方法。以一个具有不同样式块的网格为例。

为了从视觉上较好的把相似的块联系起来，需要在必要的地方开启新行，这里是颜色改变的地方。如果每个颜色组都有一个父元素的话，我们可以使用 overflow 或者 简单清除方法。或者，在每组之间用一个空div方法。额外的 div 之前并不存在，可以自己试试来看看哪个方法好。

浮动的问题

浮动因脆弱而饱受诟病。大多数的脆弱性来自于 IE6 及其一系列的浮动相关 bug。因为越来越多的设计师不再支持 IE6 了，你也可以不关注它了。不过对于那些要关注的人来说，这里有些大概。

• 推倒是浮动元素内的元素（大多是图片）比浮动元素本身宽造成的现象。大多数的浏览器会在浮动之外渲染图片，但是不会有伸出来的部分影响其他布局。IE 会扩展浮动来包含图片，精彩大幅度地影响布局。一个普遍的例子是突破伸出主内容之外把侧栏推到下面。快速修正：确保不是图片造成这种情况，使用 overflow:hidden 来切除多余的部分。
• 双倍边距bug处理 IE6 时，另一个需要记住的事情是，如果在和浮动方向相同的方向上设置外边距(margin)，会引发双倍边距。快速修正：给浮动设置 display:inline; 而且不用担心，它依然是块级元素。
• 3像素间距是指挨着浮动元素的文本会神奇的被踢出去3像素，好像浮动元素的周围有一个奇怪的力场一样。快速修正：在受影响的文本上设置宽度或高度。
• IE7 中，底边距 bug是当浮动父元素有浮动子元素时，这些子元素的底边距会被父元素忽略掉。快速修正：用父元素的底内补白(padding)代替。

替代品

如果需要文本环绕图片，除了 float 之外还真没多少替代品。说到这，可以看看这个使文本围绕不规则形状的聪明技术。对于页面布局，肯定有很多选择。Eric Sol 在 A List Apart 上有一篇文章人造绝对定位，介绍了一个很有意思的技术，它在很多方面把浮动的扩展性和绝对定位的实力结合起来。CSS3 有Template Layout Module，当它被广泛支持时，将会是一个页面布局技术的选择。

视频

作者还贴心地做了一个视频来解释相应的概念。