使用复合选择器和从右到左解析的 CSS 性能

Question

我无法在官方文档中找到，也无法在我读过的许多文章中找到如何使用复合选择器解析 CSS。

旁注:显然，在某些特定需求中使用复合选择器是有原因的；是的，后代选择器很昂贵。

大多数文章只是验证 CSS 是像这样从右到左阅读的:

div.some-class li a

这些文章的作者是这样说的:

First, all anchor elements are matched, then the parser looks for a list-item as an ancestor, then it looks for an ancestor div with the class of "some-class."

在这些描述中，CSS 解析器似乎将空格分隔的组合器视为单个单元，而不是在给定的复合选择器中从右到左阅读。

所以我在网上和工作中看到的一个非常普遍的论点是 div.some-class 比 .some-class 快，因为，“它只需要看在具有该类的 div 中。”但是，这只有在 CSS 是从左到右阅读时才有意义，或者如果在复合选择器中有一个异常(exception)以获得更好的性能，它会先找到元素集合，然后再查看是否有匹配的类。

但是，使用上面的例子，我的理解是这样的:

All a elements are matched, then if there is an li ancestor it's still matched, then it looks for ANY ELEMENT ancestor with a class of "some-class", THEN it checks if that element is a div. If so, the styles will be applied.

真正的问题:

1) div.some-class 是否仍然以复合形式从右到左阅读；或者，

2) 作为复合选择器，CSS 解析器是否首先找到所有祖先 div，然后查看它们是否具有该类？

答案的官方来源是我最感兴趣的。

可能的答案:假设 document.querySelectorAll 使用 CSS 解析引擎而不是它的 JavaScript“版本”，我发现了以下内容:

Based on a test I did with 200,000 p elements on a page, and all with the class of "p" on them. Querying .p repeated in a loop 100X, vs p.p showed that .p is the fastest in Chrome 53. Selecting p.p takes 1.71X as long. I repeated the process 8 times and averaged the numbers to get the difference. .p = 2,358 ms and p.p = 4,036 ms.

function p() {
    var d = Date.now();
    var a = [];
    var i = 0;
    function fn() {
        a.push(document.querySelectorAll(".p").length);
    }
    for (;i<100;i++) {
        fn();
    }
    console.log(".p = " + (Date.now() - d));
}

function pp() {
    var d = Date.now();
    var a = [];
    var i = 0;
    function fn() {
        a.push(document.querySelectorAll("p.p").length);
    }
    for (;i<100;i++) {
        fn();
    }
    console.log("p.p = " + (Date.now() - d));
}

在 Chrome 53 中，似乎复合选择器实际上仍然是从右到左读取的，这使得 element.class 复合选择器比单独按类选择要慢得多，对于属性而不是类也是如此。

在 IE11 中，它主要是相反的。虽然速度没有明显加快，但具有 element.class 或 element[attribute] 的复合选择器实际上比单独按类或属性获取元素更快。

Answer 1

复合选择器不一定按任何特定顺序求值。例如，大多数(如果不是全部的话)实现都针对 ID、类和类型选择器进行优化以快速匹配或快速失败(至少 Gecko 是 according to Boris Zbarsky )，然后根据需要评估属性选择器和伪类。

预测任何给定浏览器(更不用说所有浏览器)将如何准确地评估复合选择器是不可行的，更不用说包含多个复合选择器的复杂选择器中的每个复合选择器了，但是我们做 知道从右到左的匹配从最右边的复合选择器开始，然后向左逐步匹配，直到匹配失败。

请务必注意，这只是供应商商定的实现细节 — 您可以根据需要实现选择器匹配，但只要您将正确的元素与正确的选择器匹配，您的实现就会符合标准.

但最重要的是，在现实世界中，这一切都可能无关紧要。编写可读且有意义的选择器，不要不必要地夸大它们，尽可能避免特异性 hack，你应该做得很好。