[译]高效的呈现CSS

原文：http://css-tricks.com/efficiently-rendering-css/
中文：http://www.vfresh.org/w3c/1034

只做重点翻译.

从右到左的解析

浏览器解析CSS的时候是从右至左，例如：ul > li a[title="home"]这个选择器中，浏览器首先解析是a[title="home"]，这部分也被称为“选择器主键”，即最终将选择的元素。

ID选择符最高效，通配选择符最低效

从高效到低效，有四种选择符：ID,类,标签以及通配符。

css

css
#main-navigation { } /* ID (最快的) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* 类 */
ul li a.current { } /* 类 *
ul { } /* 标签 */
ul li a { } /* 标签 */
* { } /* 通配符(最慢的) */
#content [title='home'] /* 通配符 */

结合上面说的“浏览器从右至左解析”，下面的这个选择器就不是那么高效了：

css

#main-nav > li { } /* 低于预计的效率 */

这让人非常的疑惑，我们原以为浏览器会先匹配最高效的ID，然后再去找那该死的子元素li。但事实是更该死的浏览器会先去找低效的li。

不要使用标签筛选

绝对不要这么用：

css

ul#main-navigation { }

ID是唯一的，所以没必要再用个标签，脱裤子放屁的事咱ITer不能做。
同样的，对于类(class)也应该尽量避免，除非你想实现同一类名根据标签来做不同的表现。

包含选择器是最烂的

David Hyatt曾说过：

CSS中最耗资源的就是包含选择器(Descendant Selectors)，特别是这些选择器是标签或通配符时，资源开销会大的恐怖。

也就是说，这个选择器是相当的低效：

css

html body ul li a { }

墙内音：fuuuuuuck ie6

一个失败的选择器比一个成功的选择器更高效

我不确定这一条的实用性，因为在你的css里面出现着一堆一堆的无效的选择器，好像呃，非常的诡异。但还是得记录一下，当浏览器从右至左解析选择器的时候，一旦无法匹配就会立即停止解析。

写选择器的时候思考一下为什么

例如这个选择器：

css

#main-navigation li a { font-family: Georgia, Serif; }

只是用来申明字体类型(font-family)，不必要指定的如此详细（除非你是重设font-family），可以通过继承的方式使之更高效：

css

#main-navigation { font-family: Georgia, Serif; }

全文主要内容译完
作者还提醒大家：不要为了优化css选择器效率而损失css的可维护性、语义化，这样就得不偿失了。本文只是希望你能认识到，css可以写的更好更漂亮。

另外，css选择器在一些JavaScript库中同样有用到，这些概念也同样适用；ID最高效，复杂、包含选择器这类是低效的。