shadow DOM <style> 中的 CSS 优先级答案

【问题标题】：CSS precendence in shadow DOM <style>shadow DOM <style> 中的 CSS 优先级
【发布时间】：2019-07-19 22:16:07
【问题描述】：

CSS 优先规则对 shadow DOM 中的 <style> 标记有何规定？

我有一个元素 <component class="component">，这是一个包含在 <head> 中的 CSS 文件，其中包含：

component {
    display: inline-block;
}

还有一个影子 DOM 中的 <style> 标签：

::slotted(.component) {
    display: block;
}

如果我理解正确，第一条规则应该具有0.0.1 的特异性，因为它有一个元素，第二个规则的特异性应该是0.1.1，因为它有一个伪元素和一个类。因此，第二个更具体，应该覆盖第一个。虽然这不会发生。在开发人员控制台 (Chrome) 中，我看到了这两个规则，它们都没有被划掉，在“计算样式”面板中，我看到“显示：内联块”。

cmets 中要求的更详细示例：

<head>
    <style>
        /* "other-component" related styles: */
        other-component {
            display: inline-block;
        }
    </style>
</head>
<body>
    <some-component>
        #shadow-root:
            <style>
                slot[name=some-slot]::slotted(*) {
                    display: block; /* Only works with !important. */
                }
            </style>
            <slot name="some-slot"></slot>
        <!-- The actual ("light-dom") content: -->
        <other-component slot="some-slot"></other-component>
    </some-component>
</body>

【问题讨论】：

不，我的意思是开槽 - 以 :host 内部的元素为目标，并带有一些槽属性。我简化了一下，原来的选择器是[slot=...]::slotted(...)
那么Shadow DOM是怎么定义的，light DOM里有什么？
什么意思？您是在询问“shadow DOM”的确切定义吗？

标签： css shadow-dom css-specificity

【解决方案1】：

此行为在CSS Scoping Module Level 1 Draft §3.3 中定义：

当比较两个具有不同树上下文的声明时，对于正常规则，在包含阴影的树顺序 [the first, global rule] 中较早的声明获胜，而对于重要规则，在包含阴影的树 [the second, ::slotted(*) rule] 顺序中较晚的声明赢了。

注意：这与作用域样式的工作方式相反。

在other worlds:

分发前应用的样式在分发后继续应用。

【讨论】：

【解决方案2】：

我们可能在https://github.com/w3c/csswg-drafts/issues/2290#issuecomment-382465643对设计有最深入的解释

目前的设计有几个原因：

我们故意完全不涉及特异性。这样做会暴露组件的实现细节，这会使代码变得脆弱——如果组件被更新并更改了它使用的确切选择器，它可能会开始覆盖以前获胜的外部规则，反之亦然，并且对于组件的用户来理解或操纵它。

所以我们必须以其他方式做出决定。文档顺序（最后的级联步骤）在这里实际上不起作用 - 它添加了对您加载自定义元素的确切方式的意外依赖，并且可能有有趣的竞争

所以我们只剩下 Cascade Origin 或接近它的东西，它只是毫无保留地使一个或另一个获胜。实际上，在列表中注入一个新的来源似乎不是一个好主意。尚不清楚用户与作者样式表应如何与之交互。因此，我们为此添加了另一个级联步骤。

最后，我们必须决定哪个获胜。我们已经知道无论我们选择什么顺序，!important 都应该有相反的顺序；这就是级联起源已经起作用的方式。所以我们必须决定外部页面是否默认获胜，但组件在！important 中获胜，或者相反。我们认为前者更有意义；这意味着组件作者的常规样式是“默认”，组件用户的样式（！important 与否）可以覆盖它，组件作者的 !important 样式可用于“锁定”需要保持原样的样式.反过来似乎也不能满足用例：这意味着组件用户默认不能覆盖样式；他们必须使用 !important 才能这样做，可能会干扰他们的其他风格；然后组件作者将无法“锁定”样式。

【讨论】：