为什么浏览器从右到左匹配CSS选择器？
浏览器引擎从右到左匹配CSS选择器。 所以他们首先找到孩子，然后检查他们的父母，看看他们是否符合规则的其余部分。
对我来说，最简单的方法就是使用元素数最少的选择器。 所以ID首先（因为他们应该只返回1个元素）。 然后可能是类或节点数最少的元素 - 例如，页面上可能只有一个跨度，因此可以使用任何引用跨度的规则直接转到该节点。
以下是一些支持我的说法的链接
这听起来像是这样做的，以避免必须查看所有父母的孩子（可能很多），而不是所有必须是一个孩子的父母。 即使DOM很深，它也只会在RTL匹配中查看每个级别的一个节点，而不是多个节点。 评估CSS选择器LTR或RTL更简单/更快吗？
请记住，当浏览器进行选择器匹配时，它有一个元素（它试图确定样式的元素）以及所有规则和它们的选择器，并且它需要找到哪些规则匹配元素。 这与通常的jQuery不同，比如说，你只有一个选择器，并且你需要找到与该选择器匹配的所有元素。
如果您只有一个选择器，并且只有一个元素与该选择器进行比较，则在某些情况下，从左到右更有意义。 但这绝对不是浏览器的情况。 浏览器正在尝试呈现Gmail或其他任何内容，并且有一个<span>尝试创建样式，并且Gmail放入其样式表的10,000多条规则（我没有创建该数字）。
特别是，在浏览器正在查看大多数选择器的情况下，它正在考虑与所讨论的元素不匹配。 所以这个问题变成了决定选择器不尽快匹配的问题。 如果在匹配的情况下需要额外的工作，那么由于在不匹配的情况下保存的所有工作，您仍然会赢。
如果您只是将选择器的最右侧部分与您的元素进行匹配，那么机会就不会匹配，您就完成了。 如果它匹配，则必须做更多的工作，但只与树深度成比例，在大多数情况下这并不是那么大。
另一方面，如果你通过匹配选择器的最左边部分开始......你将它与什么匹配？ 你必须开始走DOM，寻找可能匹配它的节点。 只是发现没有任何匹配，最左边的部分可能需要一段时间。
所以浏览器与右边相匹配; 它提供了一个明显的起点，并且可以让您快速摆脱大部分候选选择器。 你可以在http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665看到一些数据（虽然这个表示很混乱），但结果是特别针对Gmail两年前，对于70％的（规则，元素）对，您可以在检查规则的最右侧选择器的标记/类/标识符部分后判断规则不匹配。 Mozilla的页面载入性能测试套件的相应数字为72％。 因此，尽可能快地摆脱所有规则的三分之二是非常值得的，然后只需要考虑匹配剩下的三分之一。
还要注意的是，浏览器已经做了其他优化，以避免即使试图匹配绝对不匹配的规则。 例如，如果最右边的选择器有一个id，并且该id与该元素的id不匹配，那么将不会尝试将该选择器与Gecko中的该元素进行匹配：尝试的“具有ID的选择器”集合来自元素ID的哈希表查找。 因此，这是70％的规则，它们具有相当好的匹配机会，在考虑最右边选择器的标签/类/标识后仍然不匹配。
从左到右的解析，也称为自底向上解析对于浏览器来说实际上是有效的。
考虑以下：
#menu ul li a { color: #00f; }
浏览器首先检查a ，然后是li ，然后是ul ，然后是#menu 。
这是因为浏览器扫描页面时，只需查看当前元素/节点以及它扫描的所有以前的节点/元素即可。
需要注意的是浏览器开始处理它得到一个完整标签/节点的时刻，并且不需要等待整个页面，除非它发现了一个脚本，在这种情况下，它暂时暂停并完成脚本的执行，然后前进。
如果相反，它会效率低下，因为浏览器发现它在第一次检查时正在扫描的元素，但后来被迫继续查看所有其他选择器的文档。 为此，浏览器需要具有整个html，并且可能需要在开始css绘制之前扫描整个页面。
这与大多数库解析dom是相反的。 在那里构建了dom，它不需要扫描整个页面，只需找到第一个元素，然后继续匹配其中的其他元素。
它允许从更具体到不太具体的级联。 它还允许在应用中发生短路。 如果更具体的规则适用于父规则适用的所有方面，则会忽略所有父规则。 如果父代中有其他位，则应用它们。
如果你反其道而行，你可以根据父母进行格式化，然后在每次孩子有不同的东西时重写。 从长远来看，这是比忽略已经处理好的规则中的项目更多的工作。
链接地址: http://www.djcxy.com/p/22871.html上一篇: Why do browsers match CSS selectors from right to left?
下一篇: Is there a CSS selector for the first direct child only?