请记住，当浏览器进行选择器匹配时，它有一个元素(它试图确定样式的元素)和所有的规则及其选择器，它需要找到哪些规则与元素匹配。这与通常的jQuery不同，在jQuery中，您只有一个选择器，并且需要找到与该选择器匹配的所有元素。

如果只有一个选择器，并且只有一个元素与该选择器进行比较，那么在某些情况下，从左到右更有意义。但这显然不是浏览器的情况。浏览器试图呈现Gmail或任何东西，并有一个<span>，它试图样式化和Gmail放在样式表中的10,000多个规则(我没有编这个数字)。

特别是，在浏览器查看它所考虑的大多数选择器都不匹配所讨论的元素的情况下。所以问题就变成了决定选择器是否匹配得尽可能快;如果这需要在匹配的情况下做一些额外的工作，你仍然会赢，因为你在不匹配的情况下节省了所有的工作。

如果你一开始只是匹配选择器最右边的部分，那么它很可能不匹配，你就完成了。如果匹配，则必须做更多的工作，但只与树深度成正比，在大多数情况下树深度并不大。

另一方面，如果你从匹配选择器最左边的部分开始…你把它和什么比赛?您必须开始遍历DOM，寻找可能与之匹配的节点。只是发现最左边的部分没有匹配的东西可能需要一段时间。

So browsers match from the right; it gives an obvious starting point and lets you get rid of most of the candidate selectors very quickly. You can see some data at http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (though the notation is confusing), but the upshot is that for Gmail in particular two years ago, for 70% of the (rule, element) pairs you could decide that the rule does not match after just examining the tag/class/id parts of the rightmost selector for the rule. The corresponding number for Mozilla's pageload performance test suite was 72%. So it's really worth trying to get rid of those 2/3 of all rules as fast as you can and then only worry about matching the remaining 1/3.

Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won't match. For example, if the rightmost selector has an id and that id doesn't match the element's id, then there will be no attempt to match that selector against that element at all in Gecko: the set of "selectors with IDs" that are attempted comes from a hashtable lookup on the element's ID. So this is 70% of the rules which have a pretty good chance of matching that still don't match after considering just the tag/class/id of the rightmost selector.

它允许从更具体的级联到不太具体的级联。它还允许在应用中短路。如果更具体的规则应用于父规则应用的所有方面，则所有父规则都将被忽略。如果父节点中有其他位，则应用它们。

如果你反过来，你会根据父文件格式化然后每次子文件有不同的内容时都重写。从长远来看，这比忽略规则中已经处理好的项要多得多。

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

考虑以下几点:

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

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

这是因为当浏览器扫描页面时，它只需要查看当前的元素/节点和它扫描过的所有之前的节点/元素。

需要注意的是，当浏览器获得一个完整的标记/节点时，它就开始处理，不必等待整个页面，除非它找到一个脚本，在这种情况下，它会暂时暂停并完成脚本的执行，然后继续前进。

如果反过来做，效率会很低，因为浏览器在第一次检查时找到了它正在扫描的元素，但随后被迫继续在文档中查找所有其他选择器。为此，浏览器需要有整个html，可能需要在开始css绘制之前扫描整个页面。

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

请记住，当浏览器进行选择器匹配时，它有一个元素(它试图确定样式的元素)和所有的规则及其选择器，它需要找到哪些规则与元素匹配。这与通常的jQuery不同，在jQuery中，您只有一个选择器，并且需要找到与该选择器匹配的所有元素。

如果只有一个选择器，并且只有一个元素与该选择器进行比较，那么在某些情况下，从左到右更有意义。但这显然不是浏览器的情况。浏览器试图呈现Gmail或任何东西，并有一个<span>，它试图样式化和Gmail放在样式表中的10,000多个规则(我没有编这个数字)。

特别是，在浏览器查看它所考虑的大多数选择器都不匹配所讨论的元素的情况下。所以问题就变成了决定选择器是否匹配得尽可能快;如果这需要在匹配的情况下做一些额外的工作，你仍然会赢，因为你在不匹配的情况下节省了所有的工作。

如果你一开始只是匹配选择器最右边的部分，那么它很可能不匹配，你就完成了。如果匹配，则必须做更多的工作，但只与树深度成正比，在大多数情况下树深度并不大。

另一方面，如果你从匹配选择器最左边的部分开始…你把它和什么比赛?您必须开始遍历DOM，寻找可能与之匹配的节点。只是发现最左边的部分没有匹配的东西可能需要一段时间。

So browsers match from the right; it gives an obvious starting point and lets you get rid of most of the candidate selectors very quickly. You can see some data at http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 (though the notation is confusing), but the upshot is that for Gmail in particular two years ago, for 70% of the (rule, element) pairs you could decide that the rule does not match after just examining the tag/class/id parts of the rightmost selector for the rule. The corresponding number for Mozilla's pageload performance test suite was 72%. So it's really worth trying to get rid of those 2/3 of all rules as fast as you can and then only worry about matching the remaining 1/3.

Note also that there are other optimizations browsers already do to avoid even trying to match rules that definitely won't match. For example, if the rightmost selector has an id and that id doesn't match the element's id, then there will be no attempt to match that selector against that element at all in Gecko: the set of "selectors with IDs" that are attempted comes from a hashtable lookup on the element's ID. So this is 70% of the rules which have a pretty good chance of matching that still don't match after considering just the tag/class/id of the rightmost selector.