css选择器为什么是从右到左解读的

快乐打工仔 分类:实例代码

可能很多朋友都认为css的选择器是从左到右解读的,如下代码:

div p a{
  /*code*/
}

可能很多人都认为顺序是这样的,那就是从div检查,然后是p,最后是a,由此来确定元素是不是应用此css样式。

事实并非如此,css选择器是从右到左进行检查匹配的,这主要是为了效率考虑,下面就进行以下介绍。

浏览器的渲染过程以谷歌浏览器为例,大致如下图:

前端教程

HTML经过解析生成DOM Tree;在CSS解析完毕后,需要将解析的结果与DOM Tree的内容一起进行分析建立一棵 Render Tree,最终用来进行绘图。Render Tree中的元素(WebKit 中称为renderers,Firefox下为frame)与DOM元素相对应,但非一一对应:

(1).一个 DOM 元素可能会对应多个 renderer,如文本折行后,不同的行会成为render tree种不同的renderer。

(2).有些DOM元素被Render Tree完全无视,比如 display:none的元素。在建立Render Tree时(WebKit 中的「Attachment」过程),浏览器就要为每个DOM Tree中的元素根据 CSS 的解析结果(Style Rules)来确定生成怎样的 renderer。对于每个DOM元素,必须在所有Style Rules中找到符合的 selector 并将对应的规则进行合并。选择器的解析实际是在这里执行的,在遍历 DOM Tree 时,从Style Rules中去寻找对应的selector。有时候css代码的数量是相当庞大的,但是对于单个DOM元素来说,也许只有几个选择器是匹配的,也就是说能够匹配的css选择器绝大多数情况下是占少数的,所以我们需要选择一个更为高效的方式来确定哪些css选择器是匹配的,下面就分别对比一下从左到右和从右到左的的效率问题。以如下选择器为例子:

div > div p em

如果有是从左到右,首先就要检查当前元素到html的整条路径,找到最上层的 div,再往下找,如果遇到不匹配就必须回到最上层那个 div,往下超找div去匹配选择器中的第一个div,回溯若干次才能确定匹配与否,效率很低。

逆向匹配则不同,如果当前的DOM元素不是selector最后的em,那只要一步就能排除。只有在匹配时,才会不断向上找父节点进行验证,这样效率是不是会高很多。

css选择器为什么是从右到左解读的,这样的场景在实际项目中还是用的比较多的,关于css选择器为什么是从右到左解读的就介绍到这了。

css选择器为什么是从右到左解读的属于前端实例代码,有关更多实例代码大家可以查看

回复

我来回复
  • 暂无回复内容