CSS Selectors Level 4介绍了快速配置文件和完整配置文件的概念。
“普通的CSS解析器”not suppose that id is unique（！），也就是说，解析器算法假设该文档具有带有重复（非唯一）值的id属性的元素。因此，在“普通的CSS解析器”中，像#myID {...}这样的CSS行的解析具有解析.myClass {...}的相同算法。将来，使用CSS4标准和快速配置文件，render engine将在“解析快速配置文件文档更快“或”解析完整的个人资料文档“。
这是一个简单的computational performance问题......
快速配置文件 的CSS解析算法，解析“好文档”，假设文档具有唯一ID，可以更快？
当我使用DOM实现CSS解析时，答案是是，因为在解析“好文档”时（不是带有重复ID的丑陋文档）我可以使用getElementById()方法，这更快（！）......但这个问题不是关于DOM解决方案，而是关于流行/严重的渲染引擎（如Blink，Geckoor或Webkit）中使用的算法。
... 总结使用唯一ID进行的可能优化（我们使用非唯一ID丢失）：
id值的第一个元素出现。 getElementById()等（更快）方法来解析#myID {...}等CSS行。:has()关系伪类的快速解析，当涉及id时，如:has(#myId) ...所以，也许，我们可以将:has(#myId)添加到快速配置文件 definition！......他们只是我的“个人假设”，对于现实生活渲染引擎可能不是这样，即使在渲染好（不丑）文档时也是如此。
答案 0 :(得分：5)
这里有很多，我不知道从哪里开始。我猜TL; DR只是几个快点：
事情并不像你认为的那样真实地发挥作用，但这非常复杂，我正考虑在其上写一篇文章。
您误解了快速/完整配置文件的意图/原因。我想可能名字没有帮助，我最近suggested we change them帮助避免这种特殊的混淆 - 但理解/真正理解为什么它重要仍需要理解＃1。
正因为如此，实际情况是您所建议的更改会降低性能而不是增加性能，并最终无法改变:has()的实际问题。
尝试用尽可能少的单词来澄清：CSS，即应用样式的部分对动态树进行澄清，包括在下载和解析HTML时。很难简单地说明（我会在我的帖子中尝试，但是如果我完成它的话），但是一个非常简单的方法的纯粹数学会像The Towers of Hanoi一样爆炸，它会在＃{3}}中出现。绝对必要 - 至少如果你真的想以我们一直以来的方式查看页面 - 我们保留了CSS现有约束中固有的智能观察的某些方面。从字面上看，所有这些观察都与规则如何与动态树有关，以及如何通过消除必须检查的元素数量以及基于的必须检查它们的规则数量来快速掌握数学方法。已发生的突变类型（在解析期间创建元素也被视为突变）。但是，当您编写JavaScript时，您只需将一个针对树（或树的一部分）的规则评估为一次作为时间快照，并且实际上是一个完全不同的问题，并且具有不同的答案。如何优化它。简短的回答是：你真的不需要对它进行优化（事实上，你无法对其进行优化 - 成本通常超过收益），它实际上非常简单快速。因此，像querySelector或find这样的东西有一个策略（树行走）和动态或“活动”。 CSS有另一个（再次，它很复杂，我会尝试在其他地方解释它，并在可能的情况下进行链接）。
考虑到所有这些，在querySelector的情况下，评估像:has()这样的东西实际上是微不足道的，但是如何在实时应用/动态树中实际完成这项工作是完全未知的。我们希望，只是没有人能够弄清楚如何让它变得不那么糟糕。因此，我们目前所拥有的是＆＃34;个人资料＆＃34;。像JavaScript这样的东西，甚至是印刷品都可以支持完整/静态配置文件，但就目前而言，浏览器 - 就你可以在样式表中编写并动态应用的内容 - 只能支持快速/动态配置文件。正如您所说，建议不是为浏览器选择是解析一个配置文件还是另一个配置文件（您可以在样式表中编写的内容）来支持子集和其他模式（你可以在JavaScript的树快照上评估一次的东西，以支持整个蜡球。
所有这些说，我实际上认为我们可以弄清楚如何在合理的树上获得足够的性能提升，并且在部分渲染周围有一些合理的规则和一些新的期望（可能的显示模式），它不会＃39吮吸我个人认为，如果你能做到这一点而不会伤害任何现有页面，那就足够了。意见各不相同，到目前为止，最糟糕的情况是害怕花费几分钟来绘制一个页面，加上如此多的其他提案和有限的时间，阻止了这方面的太多进展。
至于具体的ID，改变它们的意思会破坏现有的网页，而不会出现某种情况。这真的使事情变得复杂。它不仅仅是因为它们是丑陋的。它几乎是不可能完全避免的，而且从统计上来说，它似乎是当前对文件顺序的第一个定义＆＃34;在已知的情况下实际上更有用/防弹，虽然我发现它是反直觉的，但它在动态情况下也更快，内存密集度更低，而在静态情况下只有稍微慢一点（但更有弹性）。为了说明原因并不难 - 如果你开始渲染页面并找到一个ID，你可以设置它的样式。在你的模型中，如果我到达文档的末尾并找到一个ID，我必须返回并取消前一个的设计，处理反响和重排，然后返回并应用此处的样式。替代方案（当前课程）只是应用它们。真正的原因ID在CSS中是特殊的，因为它的特殊性，它更简单，更独特＆＃39;更重要的是对于CSS来说，属性，类和id之间的内部基本没有区别，它们仅仅是关于我们如何根据DOM变异来分割规则并将它们缩小。在JavaScript中，性能不是很多问题，浏览器应该实现完整/静态配置文件，包括带有或不带ID限制的:has()：）