【发布时间】：2011-04-20 13:55:46
【问题描述】：
像这样的组合子有优先级吗
a > b ~ c d
（注意c和d之间的空格是后代组合子）
还是只是从左到右阅读，比如
((a > b) ~ c) d
?
【问题讨论】：
标签： css css-selectors
【发布时间】：2011-04-20 13:55:46
【问题描述】：
不，组合器中没有优先级的概念。但是，复杂选择器中存在元素顺序的概念。
任何复杂的选择器都可以从任何对你有意义的方向读取，但这并不意味着组合符是distributive 或commutative，因为它们是indicate a relationship between two elements，例如ancestor descendant 和 previous + next。这就是为什么元素的顺序很重要的原因。
According to Google，然而，浏览器实现它们的选择器引擎，以便它们评估复杂的选择器从右到左：
引擎 [Gecko] 从右到左评估每个规则，从最右边的选择器（称为“键”）开始，遍历每个选择器，直到找到匹配项或丢弃规则。
Mozilla 的文章Writing Efficient CSS for use in the Mozilla UI 有一节描述了他们的 CSS 引擎如何评估选择器。这是 XUL 特有的，但相同的布局引擎用于 Firefox 的 UI 和显示在 Firefox 视口中的页面。 （死链接）
正如谷歌在上面引用中所描述的，键选择器只是指最右边的简单选择器序列，所以它也是从右到左：
样式系统从键选择器开始匹配规则，然后向左移动（在规则选择器中查找任何祖先）。只要选择器的子树继续检出，样式系统就会继续向左移动，直到它匹配规则，或者因为不匹配而放弃。
记住两点：
-
这些是根据实施细节记录的；本质上，选择器就是一个选择器，它所要做的就是匹配一个满足特定条件的元素（由选择器的组件布置）。读取的方向取决于实现；正如另一个答案所指出的那样，the spec 没有说明评估选择器的顺序或组合优先级。
-
两篇文章都没有暗示每个简单选择器在其简单选择器序列中从左到右进行评估（请参阅this answer了解为什么我认为不是 ）。文章所说的是浏览器引擎将评估键选择器序列以确定其工作 DOM 元素是否匹配它，然后如果匹配，通过跟随组合器进入下一个选择器序列和检查与该序列匹配的任何元素，然后冲洗并重复，直到完成或失败。
话虽如此，如果您要我阅读选择器并用简单的英语描述它们选择的内容，我也会从右到左阅读它们（虽然我不确定这是否与实现细节有关！）。
所以，选择器：
a > b ~ c d
意思是：
选择任何
d元素
这是c元素的后代
那是b元素的兄弟姐妹
这是a元素的子元素（直接后代）。
【讨论】：
-
是的。从右到左，因为最后一个简单的选择器 (d) 是结果的子集。其他简单的选择器（a、b 和 c）只是为了缩小结果范围。
-
但是假设我有两个 div
#A和#B，#A里面有 100 个 span，#B只有一个。然后从左到右评估div#A span会更容易并且可能更快然后首先获得所有跨度，或者不？ -
如果我从我曾经看过的 Youtube 上的一次讲座中没记错的话，ID 选择器会得到特殊处理。如果选择器字符串包含 ID 选择器，则可能存在从右到左规则的分歧。此外，浏览器对所有具有 ID 的元素都有引用（因此它们不必为遇到的每个选择器都搜索它们）。
-
这里，这个视频和这个问题有关：youtube.com/watch?v=a2_6bGNZ7bA
-
如果您试图确定刚读入的标签是否需要在向用户显示之前应用任何 CSS 规则，则从右到左是有意义的。这是一个预渲染技巧，正确计算可能非常复杂。这就是为什么 CSS4 的某些部分，例如 :has() 会给 CSS3 引擎带来很大的麻烦。如果您想使用 CSS3 解析器，我这里有一个：github.com/cubiclesoft/ultimate-web-scraper/blob/master/support/… TagFilter::ParseSelector() 将 CSS3 选择器标记为最佳顺序。
没关系。
a > b c
无论你是否这样做，都会匹配相同的元素
(a > b) c
或
a > (b c)
我认为浏览器是从右到左的。
【讨论】：
-
将兄弟组合器添加到组合中确实很重要，就像在 OP 的示例中一样。
the spec 没有提到任何关于优先级的内容（我可以找到），但我相信这是严格的从左到右的评估
【讨论】：
-
是的，我也没有在规范中找到任何东西，这就是我问的原因:)