Une introduction aux couches en cascade CSS

Les couches en cascade introduisent la nouvelle règle at de @layer. L'intention est d'aider les auteurs CSS à être plus intentionnels dans l'ordre des « couches » de règles CSS en tant que nouvelle méthode de gestion en cascade.

CSS a récemment eu 25 ans et, au cours de cette période, de nombreuses techniques et outils ont été créés pour aider les développeurs à travailler avec la cascade. Au cours de la dernière année, une nouvelle spécification pour orchestrer le "C" dans CSS a été rédigée et est maintenant une recommandation candidate officielle : les couches en cascade.

Les couches en cascade permettent de contrôler la spécificité et l'ordre des ensembles de règles dans les feuilles de style.

Nous tous ont rencontré des collisions CSS et des régressions soudaines dans nos bases de code lorsque de nouveaux styles sont écrits ou que des styles tiers sont ajoutés. Cela est dû à l'interdépendance des styles en raison de l'ordre des sources, de la spécificité et de l'héritage. Certaines façons de contrôler la cascade ont inclus des méthodologies telles que ITCSS et BEM et d'autres fonctionnalités natives plus récentes telles que les propriétés personnalisées CSS et :where/:is. Les calques en cascade seront la solution native ultime pour résoudre les conflits entre plusieurs sources de styles.

Vous pouvez expérimenter les calques en cascade dans les navigateurs suivants où ils sont activés par défaut sans indicateur nécessaire :

• Chrome Canary/Chromium 99+ ,
• Firefox Nightly 97+,
• Safari Technical Preview 137+.

Que résolvent les couches en cascade ?

Miriam Suzanne, l'auteur des spécifications pour les couches en cascade, a noté dans son explication originale (certaines informations sont désormais obsolètes) que "les couches en cascade permettraient aux auteurs de définir leur propre schéma de superposition et d'éviter les conflits de spécificité ou d'ordre des sources entre les préoccupations". Nous en apprendrons plus sur ces concepts clés de spécificité et d'ordre de la source (alias "ordre d'apparition") pour mieux comprendre quand utiliser les couches.

Un principe fondamental de la cascade qui aidera à comprendre le but des couches en cascade est que des origines. Lorsque le navigateur compose des styles, il existe trois origines principales :

• Origine de l'auteur
  Les feuilles de style que vous ajoutez à votre site Web.
• Origine de l'utilisateur
  Styles que les navigateurs peuvent autoriser à fournir comme préférences tels que la police, la taille de police et les couleurs par défaut.
• Origine de l'agent utilisateur
  Les styles par défaut appliqués par le navigateur.

De plus, les transitions et les animations sont considérées comme des origines en raison du « virtuel ». règles qu'ils créent lors de l'exécution.

Ces origines sont la priorité la plus élevée lorsque le navigateur détermine quelle règle de la cascade "gagne" pour un élément donné. Chaque origine considère également si une définition est signalée par !importantce qui inverse l'ordre des origines, entraînant !important dans les origines inférieures ayant la priorité. Ainsi, l'utilisation de !important met à jour l'ordre d'origine :

1. importante origine de l'agent utilisateur,
2. importante origine de l'utilisateur,
3. importante origine de l'auteur,
4. normale origine de l'auteur,[19659007]Origine normale de l'utilisateur,
5. Origine normale de l'agent utilisateur.

L'ordre de tri en cascade détermine les styles que le navigateur appliquera. Lorsqu'un niveau supérieur ne parvient pas à résoudre les styles à utiliser, le niveau suivant est évalué jusqu'à ce qu'une déclaration gagnante soit trouvée.

L'ordre de tri par priorité est le suivant :

1. origines et importance ;
2. contexte (dans un shadow DOM, par exemple);
3. styles attachés aux éléments (dans l'attribut style);
4. spécificité;
5. ordre d'apparition – alias "le dernier gagne".

Une fois les couches en cascade sont prises en charge, elles s'inséreront dans l'ordre de tri entre les styles attachés aux éléments et la spécificité. Considérons un instant quelques-unes des nombreuses façons dont vous pourriez créer vos styles :

• le tout dans une seule feuille de style ;
• à l'aide d'un framework ;
• en utilisant un préprocesseur comme Sass ;
• avec une méthodologie comme BEM ;
• via CSS-in-JS.

Indépendamment de la façon dont vous écrivez CSS, vous ne travaillez toujours qu'au sein de l'origine author. Et au sein de cette origine, pour déterminer les "bons" styles à appliquer à un élément, vous avez affaire aux deux dernières couches de tri : la spécificité et l'ordre d'apparition. essayer de permettre aux auteurs d'exercer un certain contrôle sur la cascade. Par exemple, BEM (Block, Element, Modifier) encourage les classes pour chaque niveau de vos composants à fournir une certaine encapsulation. Lorsque la dénomination BEM est respectée, les styles résultants contournent principalement l'ordre du niveau d'apparence (à moins d'utiliser délibérément un modificateur) tout en permettant de contrôler la spécificité.

Sans ces outils et techniques comme garde-corps, il est notoirement facile de se lancer dans une bataille. contre la spécificité et l'ordre d'apparition. Même avec l'utilisation de ces approches, des styles tiers malveillants ou simplement un manque de discipline peuvent entraîner une utilisation accrue de sélecteurs plus puissants et de règles jonchées d'!important dans une tentative de reprendre le contrôle. Pour certaines personnes, cela entraîne une frustration importante lors de l'écriture de CSS.

Les couches en cascade visent à remettre le contrôle de la spécificité et de l'ordre entre les mains des auteurs. L'utilisation de @layer accorde un pouvoir explicite pour orchestrer exactement la façon dont les styles provenant de différentes sources sont évalués et priorisés.

La cascade, la spécificité et l'ordre d'apparition

Faisons un bref rappel sur les bases de la spécificité et comment l'ordre d'apparition entre en jeu. Ces concepts sont essentiels pour comprendre le fonctionnement des calques et leur puissance pour les auteurs. couleur pensez-vous que le paragraphe recevra les règles suivantes ?

p {
  la couleur verte;
}

.Royal {
  couleur : bleu roi ;
}

:premier enfant {
  La couleur rouge;
}

La balise d'élément a la spécificité la plus faible, elle n'est donc pas prise en compte car le paragraphe a une classe avec une règle de correspondance. Cependant, la classe de royal et la pseudo-classe ont la même spécificité, donc le navigateur se déplace par ordre d'apparition pour déterminer laquelle appliquer. Puisque la règle :first-child est définie en dernier, le paragraphe sera rouge.

Maintenant, si vous avez toujours voulu que la classe royal s'applique, certaines options seraient :

• ajoutez un !important à la définition de couleur;
• déplacez la règle .royal après :first-child règle ;
• augmenter la spécificité de la règle, comme la mettre à jour vers p.royal pour la puissance supplémentaire du sélecteur d'élément.

Mais il y a des conséquences pour chacun d'entre eux.

• !important est susceptible d'entraîner des problèmes de modification ultérieure de l'élément avec d'autres styles.
• Le déplacement de la règle peut ne pas être une solution permanente car vous pouvez continuer à avoir des conflits avec des règles de la même spécificité.[19659007]L'augmentation de la spécificité peut également réduire la réutilisabilité ; comme dans notre exemple, p.royal supprime la possibilité d'utiliser la classe royal pour d'autres éléments.

Passons à l'apprentissage du fonctionnement des couches en cascade et de la façon dont elles atténuent ces points de conflit.

Définition des couches en cascade

Comme indiqué dans l'introduction, les couches en cascade impliquent la nouvelle règle de @layer. Il existe plusieurs façons de définir les calques.

Le premier concept clé de l'utilisation de @layer est que l'ordre des calques est important car les calques changent la donne en matière de spécificité. Et par "ordre", nous parlons de cette idée que nous avons examinée sur "l'ordre d'apparition". Une fonctionnalité puissante des calques est que leur ordre peut être défini tôt, puis les styles ajoutés ultérieurement, ce que nous verrons bientôt. et un nom pour créer un bloc pour les styles de calque. Ici, nous créons un calque appelé base :

@layer base {
  corps { ... }
}

Vous pouvez également ajouter la fonction layer() à un @import mais gardez à l'esprit que l'utilisation de @import a un coût en termes de performances. Cependant, cette fonctionnalité peut être très utile pour définir un framework ou un script tiers en tant que couche.

 @import url(bootstrap.css) layer(bootstrap);

Instruction pour définir des calques, formatés sous forme de lignes multiples ou simples. Cette fonctionnalité devient extrêmement importante pour permettre aux auteurs de définir leur ordre de calque en un seul endroit en haut de leurs styles. Ils peuvent ensuite ajouter des styles ultérieurement via les méthodes de blocage ou d'importation en faisant référence au même nom de calque.

Dans cet exemple, nous donnons essentiellement aux styles du framework Bootstrap la priorité la plus basse en tant que calque, suivi de notre propre base styles, et enfin permettant une couche application.

@layer bootstrap, base, application ;

@import url(bootstrap.css) couche(bootstrap);

@couche de base {
  corps {... }
}

Remarque : La spécification est particulière concernant l'ordre d'inclusion de @import. Une fois que vous avez ajouté un @layer après un @importtoute utilisation de @import après ce calque sera invalide et non chargée. Donc, si vous aviez plusieurs @import à ajouter, vous devrez les regrouper avant de créer d'autres calques.

Imbriquer des calques en cascade

Vous pouvez également imbriquer @layer des règles. Ensuite, pour ajouter ultérieurement des règles imbriquées, vous référencez ensemble les règles parent et imbriquées à l'aide de la notation par points.

 @layer framework {
  @layer reset, base, composants ;
}

@layer framework.reset { ... }

Vous pouvez également définir des couches imbriquées à l'aide de la notation par points :

@layer framework.reset, framework.base, framework.components ;

Si vous -utilisez un nom dans un calque imbriqué, il ne fera pas référence au calque externe mais commencera plutôt un nouveau calque avec ce nom. Ainsi, dans cet exemple, nous créerions le calque framework.basesans ajouter de styles au calque externe base.

@layer base;

@cadre de couche {
  @couche de base { ... }
}

Calques sans nom

Enfin, la dénomination est facultative. Vous pouvez définir des calques sans nom (anonymes). L'inconvénient est que vous ne pouvez pas en ajouter plus tard, et où qu'ils soient ajoutés détermine leur priorité par rapport à l'ordre des autres couches.

@layer { /* rules */ }
@import url(framework.css) layer ;

Vous pouvez choisir d'utiliser des couches anonymes pour renforcer la définition des couches à un emplacement pour votre application. Ou, vous pouvez les utiliser comme couches « privées » si vous ne voulez pas intentionnellement que les auteurs ultérieurs puissent les manipuler. Alors que les règles que nous avons brièvement examinées sur la spécificité s'appliqueront toujours dans et en dehors des couches, l'inclusion des couches introduit un nouveau paradigme.

La première partie de la spécificité pour les couches est l'ordre. Par conséquent, les calques définis ultérieurement verront leurs règles prioritaires sur les calques définis précédemment. theme aura priorité sur reset et base, et les styles de calque utilities seront prioritaires sur tous les calques précédents.

Maintenant, le résultat de cette priorité pourrait vous surprendre. Rappelez-vous que les calques sont destinés à remettre le contrôle de la cascade aux auteurs. Et un élément essentiel de ce contrôle est la capacité à gérer la spécificité. Pour remplir cette intention, le comportement résultant est qu'un sélecteur plus simple dans une couche ultérieure peut remplacer ce qui aurait été historiquement un sélecteur plus fort dans une couche précédente.

Dans l'exemple suivant, le simple h2 le sélecteur d'élément rendrait tous les h2s bleus en raison de l'ordre d'apparition du calque theme après le calque base.

@layer base {
  article h2 {
    couleur violet;
  }
}

@thème de calque {
  h2 {
    Couleur bleue;
  }
}

Cependant, au sein d'une couche individuelle, les règles de spécificité classiques s'appliquent.

Remarque : Si vous imbriquez des couches, ce comportement de spécificité existe toujours. Ainsi, si les couches précédentes étaient imbriquées dans une couche frameworkle h2 dans framework.theme remplacerait toujours le h2 dans framework.base.

J'espère que la raison pour laquelle on les appelle des "calques" devient claire !

Une métaphore utilisée par le groupe CSSWG dans la planification des calques consistait à les comparer aux calques PhotoShop, où le la couche supérieure remplace les couches inférieures, mais est également « transparente » pour les parties où elle ne s'applique pas. , le groupe de travail CSS souhaitait garantir un chemin de mise à niveau. Et dans le cadre de cette discussionils ont déterminé que les styles que vous avez actuellement l'habitude d'écrire – c'est-à-dire les "styles sans calque" – auraient toujours la plus haute priorité. En d'autres termes, les styles en dehors des calques finiront par "l'emporter" sur les styles à l'intérieur des calques. , il sera remplacé par le sélecteur p qui vit en dehors d'un calque. Donc ici, le paragraphe (et tous les autres dans l'application) finirait en rouge.

@layer utilities {
  .bleu {
    Couleur bleue;
  }
}

/* gagne */
p {
  La couleur rouge;
}

Les styles sans calque ont la priorité même s'ils sont triés avant que les calques ne soient définis. Cela signifie que nous aurions pu placer la règle p avant le calque des utilitaires, et le paragraphe deviendrait toujours rouge.

Styles sans calque dans des calques imbriqués

Si vous écrivez des styles dans un calque, puis ajoutez des calques imbriqués , les règles en dehors des calques imbriqués agissent comme des styles sans calque en termes de spécificité de cascade. Dans ce bloc de calque, le paragraphe restera vert.

@layer typography {
  p {
    la couleur verte;
  }

  contenu @layer ;
}

@couche typographie.content {
  p {
    Couleur bleue;
  }
}

Ainsi, si vos calques imbriqués ont le potentiel de se remplacer, vous souhaiterez peut-être vous assurer que tous les styles avec le calque parent se trouvent eux-mêmes dans des calques.

Utilisation de !important dans les calques[19659010]Comme pour l'ordre de tri en cascade sans calque, marquer une définition de propriété comme !important augmente sa priorité. Dans les calques en cascade, l'ajout de !important inverse l'ordre de tri de sorte que les styles !important concurrents dans un calque défini précédemment l'emportent sur les styles !important dans les calques ultérieurs. Cela a été conçu pour correspondre au comportement !important que nous avons examiné pour les origines. De plus, l'utilisation de !important dans un calque l'emportera également sur un style sans calque.

Voici trois règles où color sur .lead a été marqué !important. Deux règles sont dans les calques et une dans le style sans calque. En raison de l'inversion de l'ordre de tri causée par !importantl'élément .lead est appliqué sera vert là où les couches en cascade sont prises en charge.

/* gagne */
@thème de calque {
  .mener {
    couleur : vert ! important ;
  }
}

utilitaires @layer {
  .mener {
    couleur : rouge ! important ;
  }
}

.mener {
  couleur : orange ! important ;
}

Par conséquent, pour remplacer un style marqué !important dans un calque, vous devez définir un calque avant ce calque et continuer à marquer la règle !important . Ou, supprimez l'utilisation de !important et refactorisez.

Ce CodePen inclut les styles que nous avons examinés jusqu'à présent pour démontrer les règles concernant la spécificité à l'intérieur et à l'extérieur des calques et l'impact de  ! important.

Voir le stylo [@layer specificity and !important](https://codepen.io/smashingmag/pen/podzPbJ) par Stephanie Eckles.

Au moment de la rédaction, les outils de développement du navigateur pour les implémentations actuelles des calques n'indiquaient pas qu'un style provenait d'un calque. Cependant, les outils sont en route, alors restez à l'écoute !

Combiner des couches en cascade et un préprocesseur inclut

Les préprocesseurs CSS comme Sass et LESS vous permettent de combiner des styles à partir de plusieurs feuilles de style.

Par exemple, dans Sass, vous pourriez créez votre feuille de style principale en incluant d'autres fichiers via la directive @usecomme suit :

@use "reset" ;
@use "theme";

Une fois les calques bien pris en charge, vous pouvez décider d'envelopper chaque inclusion dans un calque, en fonction de la granularité que vous préférez pour l'architecture de vos styles. Vous pouvez le faire individuellement dans chaque inclusion avant de l'utiliser, ou vous pouvez utiliser le mixin Sass intégré pour load-css pour remplir un calque avec les styles d'une inclusion :

@use 'sass : méta' ;

@thème de calque {
  @include meta.load-css('theme');
}

Si vous proposiez des styles dans un cadre ou un système de conception où les auteurs en aval pouvaient modifier les couches incluses, vous pouvez créer une liste $layers remplaçable. Ensuite, parcourez les valeurs de la liste pour générer les styles de calque correspondants. Ce code de démonstration suppose que vous avez nommé vos inclusions de la même manière que vos couches attendues.

@use "sass:meta" ;
@use "sass:liste" ;

$calques : "réinitialiser", "thème" !default ;

// Affiche la liste des calques
@couche #{$couches} ;

// Affiche les styles de chaque calque via leur inclusion
@chaque $couche dans $couches {
  @couche #{$couche} {
    @include meta.load-css($layer);
  }
}

Cas d'utilisation des calques en cascade

Nous avons beaucoup travaillé sur les règles des calques concernant la spécificité et l'ordre d'apparition. Examinons donc certains cas d'utilisation où ceux-ci sont généralement en conflit et que les couches aideront probablement à résoudre.

Lorsque vous explorez ces scénarios, gardez à l'esprit que le navigateur téléchargera toujours une feuille de style complète pour traiter les règles. Ainsi, bien que les calques puissent gérer des définitions concurrentes, méfiez-vous de la création d'un gonflement de la taille du fichier. et/ou un ensemble de styles de ligne de base. Il peut s'agir de lisser les incohérences du navigateur pour les éléments communs ou de fournir des valeurs par défaut raisonnables pour l'application attendue. Les styles de ces catégories sont généralement destinés à avoir la priorité la plus basse, ce qui en fait de bons candidats à répertorier en tant que première couche. Cette idée est bénéfique dans les autres scénarios que nous examinerons car elle conserve la même spécificité que celle initialement prévue. puis est distribué au sein d'un thème WordPress. Vous pouvez puiser dans cette couche dans la sortie d'un panneau de paramètres pour mettre à jour la font-family à une valeur définie par l'utilisateur et vous assurer que la faible spécificité est conservée par rapport à l'ajout d'un style en ligne standard.

Framework And Remplacements de bibliothèque

L'une des principales raisons pour lesquelles les gens utilisent les frameworks et les bibliothèques est les styles prédéfinis. Généralement, les auteurs du framework et de la bibliothèque auront probablement essayé de maintenir une faible spécificité et d'offrir des méthodes de personnalisation. Mais il y a toujours des situations uniques que vous, en tant qu'implémenteur, rencontrerez où vous devrez peut-être remplacer certains styles. couches. Nous avons brièvement examiné cette idée lors de l'apprentissage de la syntaxe @layer avec Bootstrap comme exemple.

Il est certainement possible qu'à mesure que les couches gagnent en prise en charge, les frameworks et les bibliothèques proposent une version qui utilise des couches, vous donnant ainsi un point d'entrée pour ajouter plus facilement vos personnalisations. Par exemple, si Bootstrap enveloppait chaque composant dans une couche, vous pouvez remplacer ses styles en appelant ce même nom de couche et en fournissant vos styles.

En gardant notre exemple Bootstrap, ils offrent Sass et la personnalisation via des variables Sass. Mais, les variables Sass sont appliquées au moment de la compilation. Ainsi, il serait toujours utile d'avoir les couches fournies par la bibliothèque disponibles si vous deviez ajouter une post-compilation de feuille de style utilisateur. apparence. Par exemple, si vous avez l'intention de remplacer les styles de composants de base tout en permettant aux styles utilitaires de modifier les variations avec succès. En raison de la spécificité entre les styles superposés et non superposés, vous courriez le risque que la spécificité des styles utilitaires ne soit plus suffisamment élevée si vous ajoutiez les personnalisations de base en tant que styles "normaux".

Mode sombre et autres thèmes

Un aspect des couches en cascade que nous n'avons pas couvertes est qu'elles peuvent être créées ou ajoutées à d'autres règles telles que @media.

L'utilisation de couches signifie que ces règles n'ont pas besoin d'être ordonnées ensuite aux règles de thème d'origine, ce qui offre plus de flexibilité dans l'architecture de vos styles. La mise à jour des valeurs à l'aide de calques dans une requête multimédia permet aux styles de conserver leur spécificité d'origine définie par l'ordre des calques. Ainsi, vous pouvez modifier les styles de manière plus sûre pour créer un nouveau thème, même si les styles résident dans des calques différents.

Vous pouvez envisager d'utiliser @layer imbriqué pour définir l'ordre d'une série de thèmes potentiels. Ensuite, vous pouvez définir les styles de calque dans la requête multimédia associée (s'il y en a une).

Nous avons défini ici une série de thèmes possibles associés aux requêtes multimédia et un dernier calque ouvert pour un utilisateur thème. Ceci illustre la définition des styles de thème dark pour mettre à jour les propriétés personnalisées associées dans la requête multimédia prefers-color-scheme.

@layer theme {
  @layer clair, sombre, contraste préféré, couleurs forcées, utilisateur ;

  @couche de lumière {
    corps {
      --fond : #f9f9f9 ;
      --couleur : #222 ;

      couleur d'arrière-plan : var(--background);
      couleur : var(--couleur);
    }
  }
}

@media (prefers-color-scheme: dark) {
  @layer theme.dark {
    corps {
      --fond : #222 ;
      --color: #fff;
    }
  }
}

Compte tenu de ce type de configuration, partout où il serait judicieux d'ajouter la feuille de style de thème utilisateur facultative, vous seriez sûr qu'elle serait en mesure de remplacer toutes les couches de thème précédemment définies.

Composants

Lorsque nous avons commencé à décrire les couches, si vous êtes habitué à une architecture de composants, vous avez peut-être pensé à créer une couche par composant. Bien que vous le puissiez certainement, gardez à l'esprit tout ce que nous avons appris sur la façon dont les couches gèrent la spécificité.

Vous souhaitez probablement que les styles de composants puissent remplacer des styles plus généraux, et vous avez deux options pour les inclure en tant que couches. Si vous incluez tous vos styles de composants dans un seul calque, alors dans ce calque, ils suivent les règles « normales » de spécificité. Cependant, si vous les divisez en calques séparés, vous accordez aux calques ultérieurs une priorité plus élevée pour remplacer les calques précédents.

Lorsque vous considérez ces options, sachez que les calques ne sont pas destinés à résoudre la portée ou l'encapsulation des styles. Pour cela, gardez un œil sur une autre spécification également rédigée par Miriam Suzanne pour la portée CSS native.

États des éléments

Un excellent cas d'utilisation pour un calque consiste à contenir des états d'élément, tels que :disabled ou :focus.

Dans le passé, j'ai écrit un sélecteur plus complexe pour ajouter des styles aux boutons où j'excluais l'état désactivé :

.bouton :not(:disabled) { ... }

Cette règle augmente la spécificité d'une manière qui doit être égalée ou dépassée par les auteurs en aval qui souhaitaient modifier les propriétés définies dans cette règle. Au lieu de cela, les calques permettront de définir des styles de composants spécifiques que des sélecteurs d'état plus simples peuvent également remplacer. :états désactivés. Ces règles d'état s'appliqueront techniquement à tout élément interactif, y compris les liens, les boutons et les éléments de formulaire.

@layer components, states;

@composants de couche {
  .bouton {
    --focus-color: rebeccapurple;
    
    couleur d'arrière-plan : rebeccapurple ;
    couleur : #fff ;
  }
}

@ états de couche {
  :désactivée {
    couleur d'arrière-plan : #ddd ;
    couleur : #999 ;
  }
  
  :focus-visible {
    contour : 2px solide var(--focus-color, currentColor) ;
    décalage de contour : 2 px ;
  }
}

Cette technique est démontrée dans ce CodePen :

Voir le stylo [@layer for element state](https://codepen.io/smashingmag/pen/MWOgmjK) par Stephanie Eckles.

Avons-nous vraiment besoin de couches en cascade ?

Si vous écrivez de petits projets confinés qui ne sont pas partagés avec un team ou non destiné à être réutilisé, vous ne verrez peut-être pas beaucoup de valeur dans les couches en cascade. Très certainement, ils ne seront pas nécessaires sur tous les projets.

Cependant, la possibilité de définir l'ordre des calques, puis de les ajouter ultérieurement dans vos feuilles de style est incroyablement puissante. Le niveau de confiance que cela permet de garantir que la spécificité voulue des styles reste intacte vaut beaucoup.

Envisagez de développer des styles pour un thème ou un système de conception, ou avec un préprocesseur ou un framework ou une bibliothèque JS. Ce sont des scénarios où vous êtes susceptible d'avoir des règles réparties sur plusieurs feuilles de style et incluses pour des raisons d'organisation globale. L'injection de calques dans ces scénarios permettrait d'ajouter et de modifier des styles sans architecture supplémentaire pour conserver l'ordre d'apparence et la spécificité d'origine. amélioration progressive. Par exemple, avec des propriétés comme aspect-ratio ou des sélecteurs comme :is()nous pouvons utiliser @supports pour inclure de nouvelles fonctionnalités tout en prenant en charge les replis. Ou, parfois, des fonctionnalités peuvent être ajoutées, et une dégradation gracieuse est acceptable sans un repli comparable.

Cependant, les couches en cascade sont un changement si global qu'il sera difficile de commencer à les utiliser jusqu'à ce qu'un polyfill soit disponible. Malheureusement, @supports ne fonctionne pas actuellement avec les règles at, et même si c'était le cas, cela ne serait pas tout à fait suffisant pour les calques en cascade puisque les styles sans calque l'emportent toujours sur les calques.

Vous pouvez certainement le faire. commencez à expérimenter les calques en cascade pour en savoir plus sur leur utilisation ! Ensuite, lorsqu'un polyfill est prêt, vous serez mieux préparé à évaluer s'il s'agit d'une fonctionnalité que vous souhaitez intégrer à vos projets. De plus, gardez à l'esprit que de plus en plus de navigateurs sont devenus "permanents", de sorte qu'après un certain temps, vous pouvez avoir l'impression que les navigateurs ont un niveau de prise en charge acceptable pour votre public. sans polyfill peut être dans quelques années, il existe encore des options CSS modernes pour aider à gérer la spécificité aujourd'hui.  :où(). Les deux pseudo-classes permettent de lister plusieurs sélecteurs entre parenthèses. La différence réside dans la façon dont ils traitent la spécificité de ces sélecteurs. )la règle entière aurait la spécificité de l'identifiant.

 :where() est toujours zéro-spécificité pour les sélecteurs répertoriés.

Particulièrement pour  :where( )l'avantage de la spécificité zéro peut être utilisé pour configurer des réinitialisations et des styles de ligne de base destinés à être remplacés. Parfois, ces styles initiaux ont augmenté la spécificité en incluant des attributs ou des états.

Par exemple, j'aime attacher la suppression du style de liste si mon élément de liste a ajouté role="list" (pour garantir que la technologie d'assistance reste l'annonce sous forme de liste). Mais, l'ajout de ce sélecteur d'attribut augmente la spécificité, et je dois l'inclure à nouveau si je veux changer le rembourrage et la marge. Donc, à la place, je peux utiliser :where() pour écrire le sélecteur avec une spécificité nulle. Cela crée une valeur par défaut sans problème pour la remplacer ultérieurement dans les styles de composants avec un sélecteur plus simple. using :is() and :where() as a cascade-control method in more depth on CSS-Tricks.

Spec Status

Cascade layers are part of the spec for “CSS Cascading and Inheritance Level 5,” which reached candidate recommendation on January 13, 2022. There are no remaining major issues yet to resolve, but you can find the previously resolved issues on GitHub.

Give cascade layers a try! If you find an issue, you can file it for the working group to consider on GitHub.

Additional Resources

(vf, yk, il)