css选择器: 编写高效的CSS选择器

高效的CSS已经不是一个新话题，也不是一个我非得重拾的话题，但是，它却是自我在SKY工作以后，真正感兴趣并始终关注的一个话题。
很多人或者忘记了，或者仅仅是没有意识到，CSS可以是高效的也可能导致低能。然而，我们可以不考虑当你自认为会的太少而使用了低效的CSS这种情况。
这些规则只真正用在性能要求很高的网站上，这些网站对速度要求很高，任何一个页面可能含有成百上千个DOM元素。但是实践出真理，不管你是在打造下一个facebook 还是在开发一个本地的展示网页，多学点总是好的....
CSS 选择器
CSS 选择器对我们大多数人来说并不新鲜，较基础的选择器分别是类型（如 div），ID（如#header）和类（如.tweet）。
较不寻常的包括基础的伪类（如:hover）和更复杂的CSS3以及 '正则'（‘regex’）选择器，比如：first-childor[class^="grid-"]。
选择器具有固有效率，引用Steve Souders的话来说，较有效到较不有效的CSS选择器的顺序是这样的：
ID,如#header
Class, 如.promo
Type, 如div
Adjacent sibling, 如h2 + p
Child, 如li > ul
Descendant,如ul a
Universal,即*
Attribute, 如[type="text"]
Pseudo-classes/-elements, 如a:hover
引用自Steve Souders的Even Faster网站
认识这很重要，虽然一个ID技术上更快而且表现更优，但几乎都不这样用。用Steve Souders的CSS测试器，我们可以发现一个 ID 选择器 和 一个类选择器 在再渲染速度方面差别很小。
在一台Windows机器上的Firefox6中，我获得了关于一个简单的类选择器的平均再渲染数据。ID选择器给出了12.5的平均值，所以实际上它要比一个类再渲染得慢一点。
ID与类之间的速度差异几乎是不相干的。
对一个类型（<a>）的选择测试，相比一个类或ID给出了慢得多的再渲染。
对一个层次非常多的子孙选择器的测试给出了 大约440的数值!
通过这我们可以发现IDs/classes与types/descendants的差别非常巨大...它们自身之间的差异很细微。
注意 这些数值在不同的机器和浏览器变化非常大。我极力建议你自己运行一下。
组合选择器
你可以单独使用一种标准选择器，如#nav，来选择所有以"nav"为ID的元素，你也可以使用组合选择器，如#nav a，来选择任何在ID为’nav’的元素里面的链接元素。
现在，我们从左到右读这个组合标签。我们先找到#nav ，然后再找到里面的元素。但是我们的浏览器不是这样解析的，它是从右到左来解析这些组合选择器的。
当我们看到#nav里面有个a，而浏览器看到的却是有个a在 #nav里面，这些细微的差异对浏览器的性能有重大影响，同事学习他们是很有价值的。
如果想知道浏览器这样解析的原因，请参考this discussion on Stack Overflow.
对浏览器来说，从最右边的元素（它最想渲染的元素）开始，然后回溯到DOM树比从DOM树的最高层开始选择向下寻找，甚至可能达不到最右边的选择器（关键的选择器）要高效。
这对CSS选择器的性能有重大影响....

本文链接http://www.cxybl.com/html/wyzz/CSS/20130915/40122.html