Le CSS : un éternel mal-aimé ? 🤔
Depuis des années, j'ai vu d'innombrables développeurs se battre avec le CSS.
On entend souvent qu'il est imprévisible, difficile à maintenir et qu'il mène inévitablement à des solutions de contournement lourdes et peu élégantes.
Mais et si le problème n'était pas le CSS lui-même, mais la façon dont on l'aborde ?
Je suis convaincu que cette frustration repose sur deux erreurs fondamentales.
1. La méconnaissance de ses fonctionnalités
Nombreux sont ceux qui n'exploitent qu'une fraction du potentiel du CSS. On se limite aux propriétés de base et on contourne les difficultés en créant des classes à tout-va, comme en témoigne l'existence d'outils comme BEM.
Cette approche, conduit trop souvent au « class hell » où l'on perd un temps fou à essayer de nommer des éléments, au lieu de s'appuyer sur la richesse native du langage.
La solution ? Plonger dans les fondamentaux :
Sélecteurs et Spécificité : Comprendre comment les sélecteurs fonctionnent (la base même du CSS) permet de cibler des éléments sans surcharger le HTML de classes.
On devrait d'abord penser balises sémantiques, pseudo-éléments, pseudos-classes, et attributs "fonctionnels".
Les classes devraient être un dernier recours, utilisées de manière utilitaire et ciblée (non générique).Propriétés adaptées au besoin : Certaines sont encore sous-utilisées alors qu’elles simplifient grandement la vie.
L’exemple le plus parlant : centrer une<div>. Il fut un temps où c’était un casse-tête, devenu même un mème sur Internet.
Aujourd’hui on utilise Flexbox partout... quitte à ignorer Grid, pourtant bien plus adapté dans la très grande majorité des cas.
Il en résulte qu'on multiplie les wrappers inutiles, et donc les classes à nommer inutilement.
2. L'absence d'architecture CSS
On pense l'architecture de notre application, mais le CSS est souvent laissé pour compte. Or, le style peut et doit aussi être structuré.
Appliquer les principes SOLID : Oui, les principes de conception logicielle — comme le SRP (Single Responsibility Principle) par exemple — s'appliquent aussi au CSS.
Chaque composant et chaque style devrait avoir une unique raison de changer, facilitant ainsi la maintenance et la réutilisation.Découper son code : Le CSS d'une application devrait refléter son architecture.
Pour un code plus propre et plus facile à gérer, il est préférable de décomposer son application en petits composants granulaires et de lier le style à chaque composant.
Mieux vaut 10 composants de 100 lignes (bien isolés) qu'un seul de 1000 lignes (où tout dépend de tout) !
Le CSS "utile" : redorer le blason d'un langage laissé de côté
Tandis que le JavaScript, le TypeScript, les frameworks comme Angular, les tests, l'architecture applicative, etc. bénéficient d'une multitude de contenus, le CSS est souvent relégué au second plan.
Il existe bien des articles et tutoriels présentant des fonctionnalités isolées, mais il y a un manque criant d'informations sur la façon de structurer, d'optimiser et de maintenir son code CSS sur le long terme.
Cet article est le premier d'une série qui a pour but de changer cela.
Je veux explorer le CSS "utile" : celui qui vous fait gagner du temps, qui simplifie la maintenance et qui vous donne un contrôle total sur votre design.
Nous verrons comment écrire des sélecteurs sans douleur, adopter les bonnes pratiques d'architecture et découvrir des astuces concrètes.
À l'heure où des solutions comme Tailwind dominent la discussion, je veux montrer que le CSS natif est non seulement une alternative viable, mais souvent une approche bien plus confortable, maintenable et scalable.
C'est en comprenant le cœur du CSS que l'on réalise que les solutions basées sur des utilitaires, le BEM, et d'autres approches similaires, répondent souvent à de fausses problématiques.
Alors, prêt(e) à se réconcilier avec le CSS ?
Top comments (0)