原文:http://css-tricks.com/efficiently-rendering-css/
中文:http://www.lizhenwen.com/w3c/1034
只做重点翻译.
从右到左的解析
浏览器解析CSS的时候是从右至左,例如:ul > li a[title="home"]
这个选择器中,浏览器首先解析是a[title="home"]
,这部分也被称为“选择器主键”,即最终将选择的元素。
ID选择符最高效,通配选择符最低效
从高效到低效,有四种选择符:ID、类、标签、通配符。
#main-navigation { } /* ID (最快的) */
body.home #page-wrap { } /* ID */
.main-navigation { } /* 类 */
ul li a.current { } /* 类 *
ul { } /* 标签 */
ul li a { } /* 标签 */
* { } /* 通配符(最慢的) */
#content [title='home'] /* 通配符 */
结合上面说的“浏览器从右至左解析”,下面的这个选择器就不是那么高效了:
#main-nav > li { } /* 低于预计的效率 */
这让人非常的疑惑,我们原以为浏览器会先匹配最高效的ID,然后再去找那该死的子元素li。但事实是更该死的浏览器会先去找低效的li。
不要使用标签筛选
绝对不要这么用:
ul#main-navigation { }
ID是唯一的,所以没必要再用个标签,脱裤子放屁的事咱ITer不能做。
同样的,对于类(class)也应该尽量避免,除非你想实现同一类名根据标签来做不同的表现。
包含选择器是最烂的
David Hyatt曾说过:
CSS中最耗资源的就是包含选择器(Descendant Selectors),特别是这些选择器是标签或通配符时,资源开销会大的恐怖。
也就是说,这个选择器是相当的低效:
html body ul li a { }
墙内音:fuuuuuuck ie6
一个失败的选择器比一个成功的选择器更高效
我不确定这一条的实用性,因为在你的css里面出现着一堆一堆的无效的选择器,好像呃,非常的诡异。但我们还是得明白:当浏览器从右至左解析选择器的时候,一旦无法匹配就会立即停止解析。
写选择器的时候思考一下为什么
例如这个选择器:
#main-navigation li a { font-family: Georgia, Serif; }
上面这段代码只是用来申明字体类型(font-family),不必指定如此详细(复杂)的选择器(除非你是想覆盖<重设>font-family)
可以通过继承的方式使之更高效:
#main-navigation { font-family: Georgia, Serif; }
全文主要内容译完
作者还提醒大家:
不要为了优化css选择器效率而损失css的可维护性、语义化,这样就得不偿失了。本文只是希望你能认识到,css可以写的更好更漂亮。
另外,css选择器在一些JavaScript库中同样有用到,这些概念也同样适用;ID最高效,复杂、包含选择器这类是低效的。