浏览器解析CSS选择器规则是从右到左解析

• 按照从上到下，从右到左的顺序解析。

duplicate

浏览器解析CSS选择器的顺序是从右到左的，而不是直观上的从左到右。
之所以是从右到左，是因为选择器一般也是有规律的，一般选择器的最右边是最宽泛的，比如div标签等，而选择器的最左边一般是最具体的，比如属性等。所以从最左边开始解析有助于能一开始就快速的判断出大部分标签是否是潜在的符合要求的目标

浏览器解析CSS选择器的顺序是从右到左的，而不是直观上的从左到右。
之所以是从右到左，是因为选择器一般也是有规律的，一般选择器的最右边是最宽泛的，比如div标签等，而选择器的最左边一般是最具体的，比如属性等。所以从最左边开始解析有助于能一开始就快速的判断出大部分标签是否是潜在的符合要求的目标
————————————————

本来以为懂了，看了楼上解释后又迷茫了

从右至左查询

浏览器对于 CSS 选择器的解析过程是从右向左的。

.class ul li span {
  // css 属性
}

如果是这样的一个结构，浏览器会从右向左开始解析。因为一般来说，最右侧的节点范围反而会比较大，越向左限定的条件就越多。也因此 CSS 的选择器设计上不宜嵌套过多，会带来性能上的问题。

参考文章：
为什么 CSS 选择器解析的时候是从右往左？

从上到下，从右到左
因为从左到右，首先浏览器会遍历你最左边的选择器，可能是div，可能是span，我需要在整个页面去把匹配成功的dom找出来，可以说是海底捞针，但是从右到左不一样了，它通过具体的遍历条件去寻找一个最匹配的值，查找之后在向上查询，是否符合自己的选择器规则，才最后匹配成功；
前者会浪费大量的遍历时间，造成大量错误的匹配结果

从上到下， 从左到右

假如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则结束这个分支的遍历。

具体参照二叉树的遍历方法

浏览器解析CSS选择器的顺序是从右到左的，而不是直观上的从左到右。
之所以是从右到左，是因为选择器一般也是有规律的，一般选择器的最右边是最宽泛的，比如div标签等，而选择器的最左边一般是最具体的，比如属性等。所以从最左边开始解析有助于能一开始就快速的判断出大部分标签是否是潜在的符合要求的目标

从右到左、从上到下依次解析

浏览器解析css选择器的规则是从右向左的，这样会提高查找选择器所对应的元素的效率

从上到下，从右到左的规则解析