Écrire du CSS efficace est suffisant pour éviter les problèmes de stylistique courants. Vraiment.
ECSS établit des règles simples pour des styliser efficacement. Plus besoin de tout nommer, plus de dépendances technologiques. Uniquement du CSS intentionnel, cohérent, simple, 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.