Écrire du CSS efficace est suffisant pour éviter les problèmes de stylistique courants. Vraiment.
ECSS établit des règles simples pour styliser efficacement. Plus besoin de tout nommer, plus de dépendances technologiques. Uniquement du CSS intentionnel, cohérent, expressif, prévisible et durable.
👮 Poussez doucement vous et votre équipe vers l’ECSS.
🏁 Un point de départ rapide & efficace est à portée de main !
📰 Allez, voyons ce que vous en pensez !
Eh bien, continuez à faire défiler la page !
Parce que le CSS en tant que langage est mal compris et injustement mal-aimé. Parce que des règles simples et des outils à faible impact peuvent grandement contribuer à garantir que la base de code CSS est légère, simple et évolutive. ECSS est une approche globale pour produire des systèmes de conception efficaces avec CSS.
Objectifs clairs, décisions rationnelles.
Chaque parcelle de CSS a un objectif. Cet objectif doit être clair pour quiconque lit le code. Que ce soit dans le HTML ou le CSS. Les sélecteurs sont le véhicule parfait pour l’intentionnalité. ECSS encourage l’utilisation de sélecteurs rationnels.
La répétition de patrons permet d’économiser du temps et de l’énergie.
Des directives de dénomination flexibles confèrent à la base de code une cohérence encourageant la standardisation et la réutilisation. Les préfixes et les directives d’utilisation appliqués via le linting garantissent que tous les membres de votre équipe suivront les règles ECSS.« Simple » consiste à écrire moins de code et à limiter les dépendances.
La soupe de classe et l’abus de div ne sont pas simples. Un nombre incalculable de requêtes @media ne le sont pas non plus. Mais le CSS moderne l’est. En acceptant CSS pour ce qu’il est (un langage de conception graphique !), vous pouvez faire beaucoup de style avec très peu de code.
Un code qui parle de lui-même est réellement accessible.
thumbnail as-circle with-border est instantanément compréhensible alors que h-10 w-10 bdr-50 br-1 overh ne l’est pas. Le code doit communiquer des informations. Plus les informations sont claires, plus il est facile de comprendre le système. Une sémantique erronée doit céder la place à l’expressivité. Les meilleures pratiques expressives fonctionnent.
L’utilisation de règles de création simples mais cohérentes conduit à la prévisibilité.
Ça fait du bien de plonger dans du code inconnu… tout en sachant déjà à quoi il ressemble. La cohérence, les modèles répétitifs, la simplicité (oui, encore une fois) se fondent dans un code prévisible. Et un code prévisible signifie moins de stress, moins de frictions et des équipes plus heureuses !
Le CSS « à la vanille » est prêt pour l’avenir.
En pratique, cela signifie être à la fine pointe du progrès et de l’évolution. Pas besoin d’attendre que des librairies tierces implémentent de nouvelles fonctionnalités. Vous pouvez utiliser clamp() dès maintenant et dire au revoir à 80 % de vos requêtes @media. Plus de sm-ceci md-cela. Uniquement du code propre et moderne.
La création CSS doit refléter les modèles, les concepts et les perspectives de conception graphique. Avec des échelles globales (désolé), des « tokens », des règles, etc., vous limitez la répétition et facilitez l’extension future de vos styles graphiques.
Rendre les parties nécessaires du CSS intelligibles aux concepteurs (codeurs ou non !) réduit le stress, le temps et favorise une bonne allocation des ressources humaines. Affiner le design dans le navigateur est un grand vecteur de rentabilité économique.
Les propriétés du modèle de boîte (display, position, width, etc.) sont extrêmement sensibles et potentiellement bien plus perturbatrices que, disons, la couleur ou la typographie. Les premiers appartiennent aux auteurs CSS professionnels et les seconds sont ceux que les concepteurs devraient pouvoir utiliser, modifier et expérimenter en contexte.
Limiter leur utilisation à ces rôles améliore la clarté et favorise la cohérence ainsi que la prévisibilité. Il en va de même pour les unités. Certaines suggèrent de la typographie, d’autres des images ou du rythme. Utilisez-les intentionnellement et rationnellement pour communiquer du sens.
Essayer de l’abstraire est vain. Au lieu de cela, la documentation et la diligence sont essentielles. Le HTML est sémantiquement riche, alors choisissez les bonnes balises et évitez de les modifier pour des raisons superficielles. On ne supprimerait ou ne modifierait pas class="header" sans d’abord comprendre son objectif, et il ne faut pas non plus modifier ou supprimer <header></header> sur un coup de tête.
Chaque particule de sélection doit avoir un but et sinon, elle doit être éliminée. Ce div étranger dans .card div h2 est ce qui rend le CSS fragile. Ce ne sont pas les “meilleures pratiques”.
Chacun d’eux peut être utile dans un certain contexte. Aucune règle d’usage absolue ne doit être édictée. Ce n’est pas « toujours » ou « jamais » mais « ça dépend » et « pourquoi ». Les règles absolues corrompent absolument. Ou quelque chose comme ça…
Néanmoins, « toujours » (hum) la garder aussi basse que possible. Oui, en 2015, cela n’était peut-être pas facile. Mais nous sommes en 2023 et de nouvelles fonctionnalités sont désormais largement prises en charge. Utilisez-les.
N’oubliez pas que CSS est un langage de conception graphique et que sa portée globale s’intègre parfaitement dans l’approche dimensionnelle fondamentalement stratifiée de la conception graphique. Les meilleures pratiques de programmation ne correspondent pas nécessairement aux meilleures pratiques de conception graphique. Adoptez les meilleures pratiques de conception graphique.
Seulement quelques déclarations par ensemble de règles uniquement. Nous parlons de rythme, de typographie, de couleur ; pas display ou position. C’est ça, le moyen de limiter la répétition, les ballonnements et la complexité.
En attendant, utilisez des éléments HTML. L’abstraction prématurée ou “résoudre des problèmes pas encore rencontrés” sont des problèmes plus importants que l’utilisation de header en CSS. Oui, ce sont les meilleures pratiques de programmation. Mais qui vous a dit que le développement CSS était purement de la conception graphique ?
Les règles devraient ensuite être centralisées en nommant et en utilisant ledit concept au lieu des règles simples. La réutilisabilité, l’expressivité et la simplicité s’en trouvent alors grandement améliorées.
Les concepts nommés ne doivent pas être définis à l’intérieur d’un autre concept nommé. Si jamais cela est nécessaire, le concept enfant doit être interne au concept parent et ne doit pas être réutilisé ailleurs.
Toutes les règles d’un concept nommé doivent résider dans le même fichier CSS unique. Pour que les auteurs et les responsables aient confiance dans le système, il doit exister une seule source de vérité pour tout concept.
Ces concepts peuvent être représentés sous forme de classes enfants ou combinées. Ne jamais utiliser ces classes seules, mais toujours en complément du concept parent. Oui, voici « jamais » et « toujours » dans la même phrase. “Double jeopardy, we are fine” dirait un grand gestionnaire.
Sauf nécessité contraire, il faut s’efforcer de maintenir la spécificité à 21 ou moins. Avec une préférence autour de 10 à 12. Il faut ici utiliser des pseudo-sélecteurs modernes et largement supportés.
L’intention peut ne pas être claire au début du travail de stylisation. Au lieu d’essayer et d’essayer en vain, un fichier de code « quarantaine » doit être utilisé temporairement jusqu’à ce que la bonne sélection se manifeste. Toutefois, aucun fichier de quarantaine ne devrait jamais être publié publiquement « en production ».
Évitez de « sur-contenir », n’utilisez pas <div> là où vous pourriez utiliser <aside>. N’enveloppez pas votre navigation à un seul niveau dans des listes à puces. Et oui, une navigation simple est accessible. « Keep it simple… Suzy », qu’ils disent en anglais.
Conformément à la célèbre meilleure pratique de programmation (encore une fois, la programmation dans la conception), les balises sémantiques sont pour… la sémantique tandis que <div> ou <span> sont destinées à la division graphique ou logique. Tout type de grille devrait être implémenté avec les balises <div>.
@media doit être incluse dans le fichier de son concept associé.Pas sous forme de fichier séparé, ni sous forme de classes suffixées. Si l’on utilise des classes utilitaires, les règles fournies ne doivent pas dépendre de la requête mais plutôt être universellement nécessaires, dans chaque configuration média.
Les requêtes @media devraient être utilisées dans les balises HTML <link> pour des considérations de réutilisation, de performance et d’optimisation. Chaque couche de fondamentale conception graphique devrait être autonome, indépendante et amovible.
Pas sous la forme d’un gros fichier minifié dans la balise <head> du document. De cette façon, le fameux problème du chargement de code CSS inutilisé est pratiquement résolu, sans aucune dette technologique. Le premier rendu est également plus rapide puisque seul ce qui est utilisé dans la fenêtre est traité par le navigateur. En prime, vous obtenez le chemin du fichier CSS dans le fichier du composant.
En adoptant la fluidité, l’adaptabilité est principalement assurée par le navigateur. Moins de règles sont nécessaires pour assurer un rendu correct dans le nombre infini de contextes d’utilisation.
En utilisant des ensembles de règles « juste à temps », des « tokens » de conception, la cascade et la sélection intentionnelle, le flux de travail de débogage et d’affinage est plus simple, plus léger et plus clair. Les « devtools » sont nos amis !
En écrivant du CSS natif, on utilise mieux le CSS ; en écrivant du HTML natif, on utilise mieux le HTML. Meilleur CSS et meilleur HTML produisent une meilleure expérience utilisateur.
Pour exclure un fichier de cette règle dans la configuration Stylelint, préfixez le nom du fichier avec un chiffre ou “x-” comme dans “x-quarantine.css”.
Des dégagements non uniformes peuvent être utilisés dans des cas particuliers pour des raisons de débordement overflow ou pour ajouter un pseudo-contenu. Si ces raisons sont absentes, il pourrait être préférable d’utiliser les marges pour créer ces espacements.
Les éléments de texte ne doivent héberger que des styles de texte, tandis que les éléments conteneurs peuvent héberger des styles de thème. Dans certains cas, les éléments conteneurs peuvent héberger des styles de texte dont les enfants hériteront.
Des marges horizontales peuvent être appliquées aux éléments de texte dans le cas d’éléments en ligne inline tels que des icônes ou des balises et sur des éléments en retrait comme blockquote.
L’héritage permet une stylistique de haut niveau. Avec peu de code, on ratisse large tout limitant la spécificité au minimum.
Les valeurs numériques ne doivent être utilisées que pour des alignements exceptionnels. Ceux-ci doivent être commentés pour communiquer l’intention. Même dans ce cas, pourquoi ne pas créer une propriété personnalisée portant un nom significatif ?
Certaines propriétés nécessitent d’être conjointes à d’autres, à l’aide d’une structure précise, pour être fonctionnelles. Il est important garder cette relation claire et explicite. L’imbrication remplit simplement ce rôle.
Tout cas de répétition d’un défaut doit être justifié dans un commentaire.
La modification de composantes et entités à travers la base de code, d’un fichier à un autre, est la plus grande source d’imprévisibilité (et probablement de frustration) du développement CSS. En forçant l’usage de préfixes explicites et exclusifs, le CSS devient substantiellement plus prévisible, expressif et robuste.
Nous proposons cette nomenclature de prefixes :
as- : forme graphique générique.of- : groupe d’éléments.is- état interactif du système.on- : interaction de l’usager.to- : rôle fonctionnel.__ : entité interne.with- : règle fonctionnelle.from-*-to- : patrons adaptatifs.&.L’usage du & dans la sélection rend l’imbrication explicite et prévient les erreurs de compréhension dues à de longues imbrications.
L’imbrication peut encourager le développement en mode « pilote automatique », sans réfléchir à notre intention de sélection. C’est l’une des raisons pour lesquelles, ultimement, nous écrirons .card div h2 au lieu de .card h2, fragilisant notre CSS. Un seul niveau d’imbrication devrait suffire dans presque tous les cas.
Le Web est fluide et la création CSS devrait adopter cette fluidité. En choisissant de limiter les dimensions de nos composants au lieu de les dicter, nous déléguons au navigateur, le laissant faire son travail. Les dimensions fixes ne devraient être appliquées qu’aux éléments graphiques tels que les images, les vidéos et les icônes.
Les identifiants id véhiculent du sens mais leur sélecteur CSS est un cauchemar de spécificité. Utilisez le sélecteur d’attribut pour conserver le sens (unicité !) tout en gardant la spécificité à des niveaux raisonnables. D’autres cas d’utilisation incluent les contrôles et champs de formulaire et les états gérés par le js (p. ex. [data-state="active"])
Utilisez ces propriétés uniquement sur les éléments qui en ont besoin. Utilisez les sélecteurs les plus étroits qui ont du sens dans le contexte.
Les entités de classe ne devraient pas être combinées à des sélecteurs de balises. Les sélecteurs génériques peuvent être utilisés comme morceau de sélection mais pas comme qualificatifs. Exceptionnellement, certaines balises à usage spécifique comme html ou body pourraient être utilisées pour restreindre l’application d’une entité de classe.
Les composants sont faits pour être insérés dans des « trous ». Ces trous sont gérés par un autre composant ou un utilitaire de plus haut niveau (p. ex. une grille ou un carrousel). Aucun composant en ce sens ne devrait incorporer de marges. Celles-ci sont appliquées en tant que rythme par un parent. Ainsi, les composants sont polyvalents et réutilisables en divers contextes.
En masquant la façon dont les navigateurs traitent les éléments débordants, nous pouvons masquer du contenu sans le savoir. En utilisant auto au lieu de hidden, le contenu débordant sera accessible et la barre de défilement signalera le problème de conception au lieu de le masquer. Masquer les barres de défilement peut être nécessaire dans certaines compositions particulières (voir l’adaptation portrait de ce même site pour un exemple !).
Ajouter un chiffre à une classe démontre une pauvre compréhension de son rôle et ne communique aucune intention claire. Demandez-vous pourquoi vous devez ajouter un chiffre et utilisez la réponse pour nommer explicitement votre classe. Si vous devez utiliser la structure pour styliser certains éléments, utilisez plutôt les pseudo-classes pertinentes.
Les choix de valeurs et d’unités doivent être dictés par le langage graphique et ses jetons de conception. Les valeurs absolues sous forme numérique doivent être réservées à des cas particuliers tels que l’alignement d’icônes sur mesure ou le dégagement d’une liste à puces. L’intention doit être claire en elle-même ou commentée sinon.
Espacer est rythmer, un concept de design fondamental. Le rythme se produit entre les éléments graphiques et doit être appliqué comme tel en CSS. Le sélecteur hibou lobotomisé (*+*) est conçu sur mesure pour cette tâche. Lorsque vous utilisez un conteneur flexible, la propriété gap fait tout pour vous !
Les unités de fenêtre d’affichage statiques (vh, vw, vmin, vmax) sont notoirement problématiques, en particulier lorsqu’elles sont utilisées comme 100vh ou 100vw. Les unités dynamiques de fenêtre sont mieux adaptées à cette tâche.
Les composants doivent prescrire une certaine structure HTML. L’utilisation de cette structure via des sélecteurs de balises intentionnels est le meilleur moyen d’assurer la persistance structurelle, de maintenir la spécificité et la complexité à un niveau faible et d’éviter de se fatiguer à force de tout nommer. Pourquoi renommer ce qui est déjà nommé ?
C’est l’une des règles les plus importantes pour parvenir à un CSS durable. Un concept autonome par fichier évite la multiplication des surcharges et redéfinitions de propriétés dans la base de code. C’est même facile à appliquer avec la configuration ECSS Stylelint.
Cette erreur, considérée à tort comme une « meilleure pratique », est à l’origine de nombreux maux de tête CSS dont nous sommes nous-mêmes responsables. Heureusement, la solution est simple : n’utilisez pas d’éléments de sélection que vous pourriez supprimer sans changer l’intention initiale.
Répéter un patron au lieu de le nommer et de regrouper ses règles dans un ensemble de règles unique est une erreur CSS classique. Et il peut être difficile de trouver et de cibler les instances de ce problème. Des outils tels que les plugins PostCSS peuvent aider en identifiant les répétitions atteignant un seuil défini dans une base de code.
Parfois, il peut être judicieux d’ajouter un div même s’il s’agit du seul enfant. Le cas d’une grille de contenu vient à l’esprit. Voir la source de cette page pour un exemple.
Il est parfois judicieux d’augmenter la spécificité. Mais ne le faites pas avant que cela ne soit prouvé nécessaire.