【第1067期】CSS选择器从右向左的匹配规则

前言

来源于朋友圈的一条动态，现在去看挺有意思了。另外不是各大校招要开始了，你懂的。今日早读文章由 @ 赵东禹分享。

正文从这开始～

下面这个栗子，CSS选择器它是如何工作的？

.mod-nav h3 span {font-size: 16px;}

如果不知道匹配规则，可能的理解是从左向右匹配:先找到.mod-nav，然后逐级匹配h3、span，在这个过程中如果遍历到叶子节点都没有匹配就需要回溯，继续寻找下一个分支。

但事实上，CSS选择器的读取顺序是从右向左。

还是上面的选择器，它的读取顺序变成：先找到所有的span，沿着span的父元素查找h3，中途找到了符合匹配规则的节点就加入结果集；如果直到根元素html都没有匹配，则不再遍历这条路径，从下一个span开始重复这个过程（如果有多个最右节点为span的话）。

在某条CSS规则下（比如.mod-nav h3 span），会形成一条符合规则的索引树，树由上至下的节点是规则中从右向左的一个个选择符匹配的节点。索引树遍历的具体过程可以看寒冬大大的一段视频。

为什么从右向左的规则要比从左向右的高效？

假如DOM的结构如上图，匹配规则是.mod-nav h3 span。

若从左向右的匹配，过程是：从.mod-nav开始，遍历子节点header和子节点div，然后各自向子节点遍历。在右侧div的分支中，最后遍历到叶子节点a，发现不符合规则，需要回溯到ul节点，再遍历下一个li-a，假如有1000个li，则这1000次的遍历与回溯会损失很多性能。

再看看从右至左的匹配：先找到所有的最右节点span，对于每一个span，向上寻找节点h3，由h3再向上寻找class=mod-nav的节点，最后找到根元素html则结束这个分支的遍历。

很明显，两种匹配规则的性能差别很大。之所以会差别很大，是因为从右向左的匹配在第一步就筛选掉了大量的不符合条件的最右节点（叶子节点）；而从左向右的匹配规则的性能都浪费在了失败的查找上面。

当然这是比较明显情况，如果在叶子上存在多个不符合条件的span，从右向左的规则也会走一些弯路（这时就需要优化CSS选择器了）。但平均来说它还是更高效，因为大多时候，一个DOM树中，符合匹配条件的节点（如.mod-nav h3 span）远远远远少于不符合条件的节点。

jQuery从1.3版本开始使用的Sizzle引擎，它按照了CSS选择器的匹配规则（从右至左）进行DOM元素的查找与匹配（当然其中做了很多优化），性能得到了很大的提升。

最后，这边有个视频是@winter之前分享的《关于浏览器的背后》，有兴趣的童鞋也可以看下：http://v.youku.com/v_show/id_XMjMzMzU2NDc2.html

为你推荐：

关于本文

作者：@ 赵东禹

原文：http://www.cnblogs.com/zhaodongyu/p/3341080.html