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。

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

html

<div class="curvedBox">
	<span>
		<span class="r1" ></span>
		<span class="r2" ></span>
		<span class="r3" ></span>
		<span class="r4" ></span> 
	</span>
	<div class="content">
	Flex is a cross-platform development framework for creating rich Internet applications (RIAs). Flex enables you to create expressive, high-performance applications that run identically on all major browsers and operating systems.
	</div>
	<span>
		<span class="r4" ></span>
		<span class="r3" ></span>
		<span class="r2" ></span>
		<span class="r1" ></span>
	</span>
	</div>

css

	ody{background-color:#000;}
	.curvedBox{width:300px;margin: 2510px auto 0;}
	.curvedBox .r1,.curvedBox .r2,.curvedBox .r3,.curvedBox .r4{background-color:#fff;display:block;overflow:hidden;height:1px;font-size:1px;}
	.curvedBox .r2,.curvedBox .r3,.curvedBox .r4{border-width:0 1px;border-left:1px solid #fff;border-right:1px solid #fff;}
	.curvedBox .r1{margin:0 6px;}
	.curvedBox .r2{margin:0 3px;}
	.curvedBox .r3{margin:0 2px;}
	.curvedBox .r4{margin:0 1px;height:2px;}
	.curvedBox .content{background:#fff;border-left:1px solid #fff;border-right:1px solid #fff;padding:0 5px;}

查看 demo

这个方法其实并不完美，其实只是利用了”无限接近”的一个概念。看放大后的图的话，可以很清楚地看到锯齿状。

锯齿

其实把图片放大足够地倍数地话，也能看到锯齿，不过放大地倍数得相当大了。将 r1 r2 r3 r4 层叠起来，利用它们 margin（left/right） 的改变以及 border(left/right)，来实现这个近似的效果。理论上，如果 rn 足够多的话，效果就会无限趋近圆弧。不过话又说回来了，多加这么多的标签和css的话，在效率上必然会存在问题，也说不上就比用图片好到哪里去。所以说，这只是提供一个思路，到底怎么用，用在哪里，还得因地制宜。

不过有第一点其实应该注意的 rn{;overflow:hidden;} 这是解决 ie 下1像素高容器的方法，ie 下当容器高度低于某些值时(如10px)，即使指定
height:1px; 得到的表现都会远高于1px，而 overflow:hidden; 是一个很好的解决方法。

这些模板是很灵活和全面的，推荐一下。

演示
下载

官方简介：
Emastic 是一个CSS框架，它将持续任务是：探索未知的新世界，寻找新的生活和新的网络空白，大胆发现CSS框架没有到达的地方。

emastic的优点：

* 轻量级 (压缩后小于4kb)
* 个性化宽度(em,px,%)
* 在网格中使用固定的或非固定的列
* Elastic使用”em”布局

Beta3更新:

* percent-grid.css (Plugin)
* absolute-grid.css (Plugin)
* semantic.css (Plugin)

Beta2更新:

* gadgets.css (Plugin)
* 垂直间距
* 改良排版 (基于网格)

官方网站：http://code.google.com/p/emastic/

The Art & Science Of CSS

很棒的价值40美金的CSS书籍，现在开始免费了，只是免费的版本中插入了某主机商的一页广告。

关于这本书，豆瓣的某网友说：想用CSS作出最帅的Menu? 想用CSS作出最帅的table? 想用CSS作出最帅的表单？ …… 这本书提供了最好的答案！

下载地址：http://twitaway.aws.sitepoint.com/ 或点击这里。

960 css system

960CSS框架是一个非常流行的CSS框架，它是国外最成熟的CSS框架之一，而且结构清晰，代码简洁，容易上手。

960的基本原理是网格技术，而且960是CSS 网格技术的最完美实现。

网格技术是最近两年才出现的一种网页布局方法，它的原理是将页面平均分割成N列，然后通过组合相应数量的列来完成对页面的布局。

关于网格技术的更多信息，请查看我之前写的《美丽网格》。

960的方法是，将页面平均分成12列或16列，然后列与列之间是完全独立的，每一列的margin和padding都是相同的，这样，每列之间就不会出现那些常见的bug。

BluePrint和YUI也有网格技术，但是它们的列与列之间的空白，是通过单边的margin来实现的，这样就需要在第一列或最后一列添加额外的样式。

然而，我之前也有一个关于网格框架的想法，后来发现与960差不多，而且在某些方面，它的实现比我的设想要好些。但是它也有点儿方法我觉得不是太 好，重用度不够，比如，对于每列的公用样式，它是通过“.grid_1,.grid_2,.grid_3, …… .grid_16{display:inline;float:left;margin-left:10px;margin-right:10px}”这 样的写法来实现的，我认为不如将这个公用的样式独立出来，写成另外的一个样式，而每列的class，只负责控制列的宽度就行了，这样比较灵活而且更简单， 更易于理解和使用。

于是我将部分代码重写了一下，发布在这里了。这个页面提供了下载链接，如果有人觉得好用，可以下载下来用。

最大的改变就是添加了个公用类column。

另外，值得一提的是，960的样式里面提供了两种清除浮动的方法，一个是.clear类，一个是著名的.clearfix，我联系了下作者，他的解释是，自己比较喜欢用clear的方法，但是同时提供两种方法供大家选择。

来源：http://www.isparkle.cn/?p=325