Co mówi zasady pierwszeństwa CSS o znaczniku <style> w cieniu DOM?

Mam element <component class="component">, plik CSS zawarty w <head> z:

component {
    display: inline-block;
}

I znacznik <style> wewnątrz niektórych cienia Dom z:

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

Jeśli rozumiem go poprawnie, pierwsza reguła powinna mieć specyfikę 0.0.1, ponieważ ma jeden element i drugą specyficzność {X1}}, ponieważ ma jeden pseudo-element i jedną klasę. Dlatego drugi jest bardziej szczegółowy i powinien zastąpić pierwszy. To jednak nie dzieje. W konsoli dewelopera (Chrome) widzę zarówno zasady, jak i żadne z nich skrzyżowane i w panelu "Obliczone style" widzę "Wyświetlacz: Inline-Block".

Bardziej szczegółowy przykład według żądanych w komentarzach:

<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>
2
egst 26 luty 2019, 14:19

2 odpowiedzi

Najlepsza odpowiedź

Takie zachowanie jest zdefiniowane w CSS Moduł SCOPING Poziom 1 Projekt §3.3:

Porównując dwie deklaracje, które mają różne konteksty drzewa, a następnie do normalnych przepisów deklaracja wcześniej w cieniu - w tym zamówienie drzewa [the first, global rule] {[the first, global rule] i dla ważnych przepisów deklarację przybywającą później w cieniu - w tym drzewo {X1}} Zamów wygrywa.

Uwaga: To jest przeciwieństwo pracy Style Scoped.

W Inne światów:

Style stosowane przed dystrybucją nadal mają zastosowanie po dystrybucji.

2
Supersharp 3 marzec 2019, 23:34

Możemy mieć najbardziej dogłębne wyjaśnienie projektu w HTTPS: / /github.com/w3c/csswg-drafts/issues/2290#issuecomment-382465643.

Kilka powodów trafiło do obecnego projektu:

Celowo nie uwzględniliśmy specyfiki w ogóle. W tym celu wystawiłoby szczegóły wdrażania komponentu, które sprawia, że kod jest krucha - jeśli komponent jest aktualizowany i zmienia dokładny wybierak, którego używa, może rozpocząć nadpisanie zasad zewnętrznych, które wcześniej wygrali lub odwrotnie i nie ma dobrego sposobu dla komponentu użytkownik, aby to zrozumieć lub manipulować.

Musimy więc zdecydować się w inny sposób. Zamówienie dokumentu (ostateczny krok kaskadowy) nie działa tutaj tak naprawdę - dodaje nieoczekiwaną zależność dokładnie, jak ładować element niestandardowy i może mieć ciekawy wyścig

Więc zostawiamy z pochodzeniem kaskadowym, czy coś blisko nie jest to bez zastrzeżeń, czyni jedną lub drugą wygraną. Właściwie wstrzyknięcie nowego pochodzenia na liście nie wydaje się świetnym pomysłem; Nie jest jasne, w jaki sposób użytkownik vs autorski arkusze w celu interakcji z tym. Więc zamiast tego dodajemy kolejny krok kaskady.

I wreszcie musimy podjąć decyzję o tym, która wygrywa. Wiemy już, że jakikolwiek wybieramy zamówienie! Ważne powinno mieć odwrotną kolejność; W ten sposób już działa kaskada. Musimy więc zdecydować, czy zewnętrzna strona wygrywa domyślnie, ale komponent wygrywa! Ważne lub odwrotne. Zdecydowaliśmy, że pierwsi dokonało więcej sensu; Oznacza to, że normalne style autora komponentu są "domyślne", stylami użytkownika komponentem (! Ważne lub nie) mogą nadejść, a komponent autora! Ważne style można użyć do "blokowania stylów", które muszą pozostać, jak oni są . Idzie kolejny sposób, nie wydawał się również spełniać przypadków użytkowania: oznaczałoby to, że użytkownicy składni nie mogą domyślnie zastępować stylów; musieliby użyć! Ważne, aby to zrobić, prawdopodobnie zakłócanie ich innych stylów; A potem autorzy komponentów nie mieliby sposobu "blokowania" stylów.

1
lkraav 23 maj 2019, 10:33