Shadow DOM中的CSS优先级

问题描述 投票：1回答：1

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）中，我看到两个规则都没有划掉，在“计算样式”面板中，我看到'display：inline-block'。

评论中要求的更详细的示例：

<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>
css shadow-dom css-specificity
1个回答
2
投票

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

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

注意：这与范围样式的工作方式相反。

在other worlds：

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

1
投票

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

目前的设计有几个原因：

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

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

所以我们留下了Cascade Origin，或者接近它的东西，只是毫无保留地赢得了一场胜利。实际上，将新的原点注入列表似乎并不是一个好主意;目前还不清楚用户与作者样式表应该如何与之互动。因此，我们为此添加另一个级联步骤。

最后，我们必须决定哪些胜利。我们已经知道无论我们选择什么订单，重要的都应该是相反的顺序;这就是级联起源已经起作用的方式。所以我们必须决定外部页面是否默认获胜，但是组件赢得了！important，或者相反。我们认为前者更有意义;这意味着组件作者的普通样式是“默认”，组件用户的样式（！重要或不重要）可以覆盖它，组件作者的！重要样式可用于“锁定”需要保持它们的样式的样式。反过来似乎也不满足用例：它意味着组件用户默认情况下不能覆盖样式;他们必须使用！这样做很重要，可能会干扰他们的其他风格;然后组件作者无法“锁定”样式。

最新问题
© www.soinside.com 2019 - 2024. All rights reserved.