高效地呈现CSS

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

 

只做重点翻译.

从右到左的解析

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

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

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

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最高效，复杂、包含选择器这类是低效的。