TL;DR
- Style queries lader en efterkommer reagere på en custom property hos en ancestor.
- Custom properties fungerer godt som komponent-input, fordi de nedarves og kan oversættes til lokale tokens.
- En variant bør ændre få design-input frem for at gentage hele komponentens styling.
Style som kontekst
En size query spørger “hvor stor er min container?”. En style query kan spørge “hvilken beregnet custom property har min container?”.
.notification { --variant: info;}
@container style(--variant: success) { .notification-content { --surface: oklch(0.94 0.05 155); --ink: oklch(0.3 0.08 155); }}Alle elementer kan fungere som style-query-container for custom properties;
du behøver ikke container-type. Det element, der styles, skal dog stadig være
en efterkommer af den container, der forespørges.
attr() og style query sammen
HTML kan eje variantens semantiske navn, mens CSS oversætter det til komponentens visuelle tokens:
<article class="notification" data-variant="success"> <div class="notification-content">Gemt</div></article>.notification { --variant: attr(data-variant type(info | success | danger), info);}
.notification-content { background: var(--surface, Canvas); color: var(--ink, CanvasText);
@container style(--variant: success) { --surface: oklch(0.94 0.05 155); --ink: oklch(0.3 0.08 155); }}Custom property-værdien nedarves til indholdet, og style queryen beskriver den
lokale reaktion. Det samme mønster kan bruges til fx featured, density eller
theme, men undgå at gøre alle DOM-attributter til et offentligt styling-API.
Fallback først
Hvis varianten er vigtig for forståelsen, så giv den en selector-baseret fallback:
.notification[data-variant="success"] .notification-content { --surface: oklch(0.94 0.05 155); --ink: oklch(0.3 0.08 155);}Style queryen kan derefter være en progressiv forbedring af arkitekturen. Det gør komponenten forståelig, selv hvis den nyeste feature mangler.