Lors de l'apprentissage des principes de base du CSS, on apprend à écrire des styles modulaires, réutilisables et descriptifs pour garantir la maintenabilité. Mais lorsque les développeurs s'impliquent dans des applications du monde réel, il semble souvent impossible d'ajouter des fonctionnalités d'interface utilisateur sans que les styles ne s'infiltrent dans des zones involontaires. Ce problème se transforme souvent en une boucle auto-réalisatrice ; les styles qui sont théoriquement limités à un élément ou à une classe commencent à apparaître là où ils n'appartiennent pas. Cela oblige le développeur à créer des sélecteurs encore plus spécifiques pour remplacer les styles divulgués, qui remplacent ensuite accidentellement les styles globaux, et ainsi de suite. Les conventions de noms de classes rigides, telles que BEM, constituent une solution théorique à ce problème. La méthodologie BEM (Block, Element, Modifier) est une manière systématique de nommer les classes CSS pour garantir la réutilisabilité et la structure des fichiers CSS. Des conventions de dénomination comme celle-ci peuvent réduire la charge cognitive en tirant parti du langage de domaine pour décrire les éléments et leur état, et si elles sont mises en œuvre correctement, elles peuvent faciliter la maintenance des styles pour les grandes applications. Cependant, dans le monde réel, cela ne se passe pas toujours ainsi. Les priorités peuvent changer et, avec le changement, la mise en œuvre devient incohérente. De petites modifications apportées à la structure HTML peuvent nécessiter de nombreuses révisions du nom de classe CSS. Avec des applications frontales hautement interactives, les noms de classe suivant le modèle BEM peuvent devenir longs et lourds (par exemple, app-user-overview__status--is-authenticating), et le fait de ne pas adhérer pleinement aux règles de dénomination brise la structure du système, annulant ainsi ses avantages. Compte tenu de ces défis, il n’est pas étonnant que les développeurs se soient tournés vers les frameworks, Tailwind étant le framework CSS le plus populaire. Plutôt que d’essayer de mener ce qui semble être une guerre de spécificité entre styles ingagnable, il est plus facile d’abandonner CSS Cascade et d’utiliser des outils garantissant une isolation complète. Les développeurs se penchent davantage sur les utilitaires Comment savons-nous que certains développeurs souhaitent éviter les styles en cascade ? C’est l’essor des outils front-end « modernes » – comme les frameworks CSS-in-JS – conçus spécifiquement à cet effet. Travailler avec des styles isolés et étroitement liés à des composants spécifiques peut sembler comme une bouffée d’air frais. Cela supprime le besoin de nommer les choses – qui reste l’une des tâches frontales les plus détestées et les plus chronophages – et permet aux développeurs d’être productifs sans pleinement comprendre ni exploiter les avantages de l’héritage CSS. Mais abandonner CSS Cascade entraîne ses propres problèmes. Par exemple, la composition de styles en JavaScript nécessite des configurations de construction lourdes et conduit souvent à des styles qui se mélangent maladroitement avec le balisage des composants ou le HTML. Au lieu de conventions de dénomination soigneusement étudiées, nous autorisons les outils de construction à générer automatiquement des sélecteurs et des identifiants pour nous (par exemple, .jsx-3130221066), obligeant les développeurs à suivre un autre pseudo-langage en soi. (Comme si la charge cognitive liée à la compréhension de tous les effets d'utilisation de votre composant n'était pas déjà suffisante !) En plus d'abstraire le travail de dénomination des classes dans les outils, le débogage de base est souvent limité à des versions d'applications spécifiques compilées pour le développement, plutôt que d'exploiter les fonctionnalités natives du navigateur qui prennent en charge le débogage en direct, telles que les outils de développement. C’est presque comme si nous devions développer des outils pour déboguer les outils que nous utilisons pour résumer ce que le Web fournit déjà – tout cela dans le but d’échapper à la « douleur » de l’écriture de CSS standard. Heureusement, les fonctionnalités CSS modernes rendent non seulement l'écriture de CSS standard plus flexible, mais donnent également aux développeurs comme nous beaucoup plus de pouvoir pour gérer la cascade et la faire fonctionner pour nous. Les couches CSS Cascade en sont un excellent exemple, mais il existe une autre fonctionnalité qui suscite un manque d’attention surprenant – bien que cela change maintenant qu’elle est récemment devenue compatible avec Baseline. La règle CSS @scope At Je considère la règle CSS @scope at comme un remède potentiel au type d'anxiété induite par les fuites de style que nous avons évoqué, un remède qui ne nous oblige pas à compromettre les avantages du Web natif au profit des abstractions et des outils de construction supplémentaires. « La règle at @scope CSS vous permet de sélectionner des éléments dans des sous-arbres DOM spécifiques, en ciblant les éléments avec précision sans écrire de sélecteurs trop spécifiques difficiles à remplacer, et sans coupler trop étroitement vos sélecteurs à la structure DOM. » — MDN
En d’autres termes, nous pouvons travailler avec des styles isolés dans des cas spécifiques sans sacrifier l’héritage, la cascade ou même la séparation fondamentale des préoccupations.cela constitue depuis longtemps un principe directeur du développement front-end. De plus, il offre une excellente couverture du navigateur. En fait, Firefox 146 a ajouté la prise en charge de @scope en décembre, le rendant ainsi compatible avec Baseline pour la première fois. Voici une comparaison simple entre un bouton utilisant le modèle BEM et la règle @scope :
La règle @scope permet une précision avec moins de complexité. Le développeur n'a plus besoin de créer des limites à l'aide de noms de classe, ce qui lui permet d'écrire des sélecteurs basés sur des éléments HTML natifs, éliminant ainsi le besoin de modèles de nom de classe CSS prescriptifs. En supprimant simplement le besoin de gestion des noms de classe, @scope peut atténuer la peur associée au CSS dans les grands projets.
Utilisation de base
Pour commencer, ajoutez la règle @scope à votre CSS et insérez un sélecteur racine auquel les styles seront étendus :
@scope (
Ainsi, par exemple, si nous devions étendre les styles à un élément
@scope (nav) { a { /* Styles de liens dans la portée de navigation */ }
a:active { /* Styles de liens actifs */ }
a:active::before { /* Lien actif avec pseudo-élément pour un style supplémentaire */ }
@media (largeur maximale : 768 px) { a { /* Ajustements réactifs */ } } }
En soi, cela n’est pas une fonctionnalité révolutionnaire. Cependant, un deuxième argument peut être ajouté à la portée pour créer une limite inférieure, définissant ainsi les points de début et de fin de la portée.
/* Tout élément à l'intérieur de ul n'aura pas les styles appliqués */ @scope (nav) à (ul) { un { taille de police : 14 px ; } }
Cette pratique s'appelle donut scoping, et il existe plusieurs approches que l'on peut utiliser, y compris une série de sélecteurs similaires très spécifiques étroitement couplés à la structure DOM, un pseudo-sélecteur :not, ou l'attribution de noms de classe spécifiques aux éléments dans le
Conclusion Les frameworks CSS axés sur les utilitaires, tels que Tailwind, fonctionnent bien pour le prototypage et les petits projets. Cependant, leurs avantages diminuent rapidement lorsqu’ils sont utilisés dans des projets plus importants impliquant plus de quelques développeurs. Le développement front-end est devenu de plus en plus compliqué ces dernières années, et CSS ne fait pas exception. Bien que la règle @scope ne soit pas une panacée, elle peut réduire le besoin d’outils complexes. Lorsqu'il est utilisé à la place ou parallèlement à la dénomination stratégique des classes, @scope peut rendre plus facile et plus amusant l'écriture de CSS maintenables. Lectures complémentaires
@scope CSS (MDN) « CSS @scope », Juan Diego Rodríguez (CSS-Tricks) Notes de version de Firefox 146 (Firefox) Prise en charge du navigateur (CanIUse) Frameworks CSS populaires (état du CSS 2024) « Le « C » en CSS : Cascade », Thomas Yip (CSS-Tricks) Introduction à BEM (Obtenir BEM)
