评估 CSS 选择器 LTR 或 RTL 是否更容易/更快？

Question

给定一个类似的 CSS 选择器

ul > li a

从左到右还是从右到左评估它会更容易/更快吗？ （我意识到“简单”和“更快”的答案可能不同。我想要两个答案）。我即将踏上其中一条道路，我不想走到一半然后意识到我选择了错误的道路:)

LTR：遍历文档中的所有元素，挑选出ul 的元素，然后检查它们的所有子元素是否有li，然后查看它们的后代元素是否有a。

RTL：遍历文档中的所有元素，找到所有a，过滤掉没有li祖先的元素，如果确实有li祖先，检查如果其父级是 ul，如果不是，则删除该 a。

此外，除了迭代所有元素之外，真的没有其他方法可以做到这一点吗？

---

我正在考虑查找元素的上下文，就像 jQuery 所做的那样，而不是应用样式的上下文。

Answer 1

浏览器和 Sizzle 选择器 JS 引擎（用于 jQuery 和其他框架）使用从右到左匹配。

在大多数情况下，从右到左是最佳的遍历解决方案。

Sizzle 优化了以 ID 开头的选择器。它首先解析具有 ID 的元素。然后它将其用作进一步遍历的上下文。

如果你有选择器

#myID > ul a

Sizzle 会首先找到带有#myID 的元素，假设在这种情况下，从左到右更优化。

Answer 2

这是每个设计和编程论坛上重复出现的问题之一。一个常见的例子也是这个帖子上的原始海报给出的例子：

ul > 丽一个

如果你遍历 ltr，你会找到所有 uls，然后是这些 uls 的所有 lis，然后是这些 lis 中的所有标签。考虑一下标记可能看起来像这样的事实：

<ul>
    <li>
        <a href="#">Click Here</a>
    </li>
</ul>

或者它可能看起来像：

<ul>
    <li>
        <span>
            <p>
                <div class="someuselessclass">
                    <span class="JunkClass">
                        <a href="#">Click Here</a>
                    </span>
                </div>
            </p>
        </span>
    </li>
</ul>

事实是，您不知道遍历需要走多远，并且在数千个这样的 LI 中可能有数千个这样的链接。在我看来，通过经验，浏览器构建者得出的结论是从右到左解析更快。

这是我的两分钱。