html - 浏览器是怎样解析css选择器的 - 为什么浏览器从右到左匹配CSS选择器?




css解析顺序 (2)

从左到右的解析,也称为自底向上解析对于浏览器来说实际上是有效的。

考虑以下:

#menu ul li a { color: #00f; }

浏览器首先检查a ,然后是li ,然后是ul ,然后是#menu

这是因为浏览器扫描页面时,只需查看当前元素/节点以及它扫描的所有以前的节点/元素即可。

需要注意的是浏览器开始处理它得到一个完整标签/节点的时刻,并且不需要等待整个页面,除非它发现了一个脚本,在这种情况下它暂时暂停并完成脚本的执行,然后前进。

如果相反,它会效率低下,因为浏览器发现它在第一次检查时正在扫描的元素,但后来被迫继续查看所有其他选择器的文档。 为此,浏览器需要具有整个h​​tml,并且可能需要在开始css绘制之前扫描整个页面。

这与大多数库解析dom是相反的。 在那里构建了dom,它不需要扫描整个页面,只需找到第一个元素,然后继续匹配其中的其他元素。

浏览器引擎从右到左匹配CSS选择器。 所以他们首先找到孩子,然后检查他们的父母,看看他们是否符合规则的其余部分。

  1. 为什么是这样?
  2. 仅仅是因为规格说明了吗?
  3. 如果从左到右进行评估,它是否会影响最终布局?

对我来说,最简单的方法就是使用元素数最少的选择器。 所以ID首先(因为他们应该只返回1个元素)。 然后可能是类或节点数最少的元素 - 例如,页面上可能只有一个跨度,因此可以使用任何引用跨度的规则直接转到该节点。

以下是一些支持我的说法的链接

  1. http://code.google.com/speed/page-speed/docs/rendering.html
  2. https://developer.mozilla.org/en/Writing_Efficient_CSS

这听起来像是这样做的,以避免必须查看所有父母的孩子(可能很多),而不是所有必须是一个孩子的父母。 即使DOM很深,它也只会在RTL匹配中查看每个级别的一个节点,而不是多个节点。 评估CSS选择器LTR或RTL更简单/更快吗?


它允许从更具体到不太具体的级联。 它还允许在应用中发生短路。 如果更具体的规则适用于父规则适用的所有方面,则会忽略所有父规则。 如果父代中有其他位,则应用它们。

如果你反其道而行,你可以根据父母进行格式化,然后在每次孩子有不同的东西时重写。 从长远来看,这是比忽略已经处理好的规则中的项目更多的工作。







css-selectors