English 浏览器引擎从右到左匹配CSS选择器。因此，他们首先找到孩子，然后检查父母，看他们是否符合规则的其余部分。
对我来说，最简单的方法是使用元素数量最少的选择器。因此，ID首先（因为它们只能返回1个元素）。然后，可能是类或具有最少节点数的元素-例如，页面上可能只有一个范围，因此请使用引用范围的任何规则直接转到该节点。
这是一些支持我的主张的链接
听起来这样做是为了避免查看父母的所有子代（可能很多），而不是查看必须是一个孩子的所有父代。即使DOM很深，它也只会在每个级别查看一个节点，而不是RTL匹配中的多个节点。评估CSS选择器LTR或RTL更容易/更快吗？
从右到左的解析（也称为自底向上解析）对于浏览器实际上是有效的。
考虑以下：
#menu ul li a { color: #00f; }
该浏览器首先检查a，然后li，然后ul，然后#menu。
这是因为在浏览器扫描页面时，它只需要查看当前元素/节点以及已扫描的所有先前节点/元素。
需要注意的是，浏览器在获得完整的标记/节点后即开始处理，无需等待整个页面，除非找到脚本，在这种情况下，浏览器会暂时暂停并完成脚本的执行，然后前进。
如果相反，它将是低效率的，因为浏览器在第一次检查时就发现了它正在扫描的元素，但是随后被迫继续在文档中查找所有其他选择器。为此，浏览器需要具有整个html，并且可能需要在启动CSS绘画之前扫描整个页面。
这与大多数库解析dom的方式相反。在那里dom被构建了，它不需要扫描整个页面，只需找到第一个元素然后继续匹配其中的其他元素。
请记住，当浏览器进行选择器匹配时，它具有一个元素（它正在尝试确定其样式的元素）以及所有规则及其选择器，并且它需要查找与该元素匹配的规则。这与通常的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％。因此，真的有必要尝试尽快消除所有规则的2/3，然后再担心匹配其余1/3。
还要注意，浏览器已经做了其他优化，甚至可以避免匹配绝对不匹配的规则。例如，如果最右边的选择器具有一个ID，并且该ID与元素的ID不匹配，则在壁虎中根本不会尝试将该选择器与该元素进行匹配：尝试的“具有ID的选择器”集合来自对元素ID的哈希表查找。因此，仅考虑最右边选择器的标记/类/ ID，这就是70％的规则很有可能匹配，但仍然不匹配。
它允许从较具体到较不具体的级联。它还允许应用中发生短路。如果更具体的规则适用于父规则适用的所有方面，则所有父规则都将被忽略。如果父级中还有其他位，则会应用它们。
如果您采用其他方法，则将根据父项进行格式化，然后在子项每次有所不同时覆盖。从长远来看，这比忽略已经处理的规则中的项目要多得多。