任何复杂的选择器都可以在任何有意义的方向读取，但这并不意味着组合器是distributive或commutative，因为他们indicate a relationship between two elements，例如。祖先后代和上一个下一个)。这就是为什么元素的顺序是重要的。

According to Google，然而，浏览器实现它们的选择器引擎，使得它们从右到左评估复杂选择器：

The engine [Gecko] evaluates each rule from right to left,starting from the rightmost selector (called the “key”) and moving through each selector until it finds a match or discards the rule.

Mozilla的文章，Writing Efficient CSS for use in the Mozilla UI有一个部分，描述他们的CSS引擎如何评估选择器。这是XUL特定的，但是相同的布局引擎用于Firefox的UI和在Firefox的视口中显示的页面。

正如Google在上面的引文中所描述的，键选择器简单地引用了最右边的简单选择器序列，因此它也是从右到左：

The style system matches rules by starting with the key selector,then moving to the left (looking for any ancestors in the rule’s selector). As long as the selector’s subtree continues to check out,the style system continues moving to the left until it either matches the rule,or abandons because of a mismatch.

记住两件事：

>这些都是基于实现细节记录的;在心脏，选择器是选择器，并且所有它打算做的是匹配满足特定条件(由选择器的组件布局)的元素。在哪个方向读取是由实现;正如另一个答案所指出的，the spec没有说明什么样的顺序来评价组合器优先级中的选择器。
>两篇文章都不暗示每个简单选择器在其简单选择器序列中从左到右求值(参见this answer为什么我认为不是这样)。文章所说的是浏览器引擎将评估关键字选择器序列，以确定其工作DOM元素是否与其匹配，然后如果匹配，则通过跟随组合器继续到下一个选择器序列，并检查匹配的任何元素序列，然后冲洗并重复，直到完成或失败。

所有这一切，如果你要求我阅读选择器，并描述他们选择的简单的英语，我会从右到左阅读他们(不是我确定这是否与实现细节相关的！)。

所以，选择器：

a > b ~ c d

将意味着：

Select any d element
that is a descendant of a c element
that is a sibling of,and comes after,a b element
that is a child (direct descendant) of an a element.