CSS选择器由浏览器引擎从右向左匹配。因此，他们首先找到孩子，然后检查他们的父母，看看他们是否符合规则的其余部分
- 为什么会这样
- 只是因为说明书上说的吗
- 如果从左到右评估，是否会影响最终布局
对我来说，最简单的方法就是使用元素数最少的选择器。所以ID优先（因为它们应该只返回1个元素）。然后可能是节点数最少的类或元素-例如，页面上可能只有一个跨距，因此使用引用跨距的任何规则直接转到该节点
这里有一些链接支持我的主张
- http://code.google.com/speed/page-speed/docs/rendering.html
- https://developer.mozilla.org/en/Writing_Efficient_CSS
听起来这样做是为了避免看到父母的所有孩子（可能是多个），而不是一个孩子的所有父母（必须是一个）。即使DOM很深，它也只会在每个级别上查看一个节点，而不会在RTL匹配中查看多个节点。评估CSS选择器LTR或RTL是否更容易/更快
请记住，当浏览器进行选择器匹配时，它有一个元素（它试图确定样式的元素）和所有规则及其选择器，它需要找到与该元素匹配的规则。这与通常的jQuery不同，比如说，只有一个选择器，需要找到与该选择器匹配的所有元素
如果您只有一个选择器，并且只有一个元素可以与该选择器进行比较，那么在某些情况下，从左到右更为合理。但这显然不是浏览器的情况。浏览器正在尝试呈现Gmail或其他内容，并且有一个<；span>它正在尝试设计样式，Gmail在样式表中加入了10000多条规则（我没有编造这个数字）
特别是，在这种情况下，浏览器会查看它所考虑的大多数选择器与所讨论的元素不匹配。所以问题变成了一个决定选择器不尽可能快地匹配的问题；如果这需要在匹配的情况下做一些额外的工作，那么由于在不匹配的情况下保存的所有工作，您仍然会获胜
如果您一开始只是将选择器最右边的部分与元素匹配，那么很可能它不匹配，您就完成了。如果它确实匹配，您必须做更多的工作，但只与树的深度成比例，在大多数情况下，树的深度并没有那么大
另一方面，如果您从匹配选择器最左边的部分开始。。。你把它和什么相匹配？您必须开始遍历DOM，寻找可能与之匹配的节点。只是发现没有匹配的最左边部分可能需要一段时间
所以浏览器从右边匹配；它提供了一个明显的起点，让您可以很快地摆脱大多数候选选择器。你可以在网站上看到一些数据http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/b185e455a0b3562a/7db34de545c17665 （虽然这个符号让人困惑），但结果是两年前Gmail占了70%（规则，元素）配对您可以在检查规则最右侧选择器的标记/类/id部分后确定规则不匹配。Mozilla的pageload性能测试套件的相应数字为72%。因此，尽可能快地摆脱所有规则中的2/3，然后只担心匹配剩余的1/3，这是非常值得的
还请注意，浏览器已经进行了其他优化，以避免尝试匹配肯定不匹配的规则。例如，如果最右边的选择器有一个id，而该id与元素的id不匹配，那么在Gecko:the set of“selectors with id”中根本不会尝试将该选择器与该元素匹配这些尝试来自对元素ID的哈希表查找。因此这是70%的规则，它们很有可能匹配但在考虑最右边选择器的标记/类/ID后仍然不匹配