FlowingDev

CSS, décodé : les règles de style qui gouvernent le web

Comprenez les feuilles de style en cascade (CSS), le langage qui met en forme les sites web, des sélecteurs et propriétés à la logique de cascade qui résout les conflits.

Essayer l'outil: Visionneuse CSS

En une phrase

Le CSS (Cascading Style Sheets, ou feuilles de style en cascade) est le langage qui indique à un navigateur web comment présenter visuellement un document, contrôlant tout, des couleurs et polices à la mise en page et aux animations.

Le problème que ça résout

Dans la soupe primordiale des débuts du web, la structure d'un document (son contenu) et sa présentation (son apparence) étaient désespérément emmêlées. Si vous vouliez qu'un titre soit gros et rouge, vous l'enveloppiez dans une balise HTML <font color="red" size="+3">. Vous vouliez changer tous vos titres en bleu ? Pas de chance. Il fallait traquer et modifier manuellement chaque balise <font> sur tout votre site. C'était un bazar immaintenable et chaotique. La mise en page était encore pire, reposant souvent sur des tableaux invisibles qui étaient un cauchemar en matière d'accessibilité et de maintenance.

Le web avait besoin d'un divorce. À l'amiable, mais nécessaire. Le contenu (HTML) devait être séparé de la présentation (le style). Ce principe, la « Séparation des préoccupations » (Separation of Concerns), est une pierre angulaire du développement logiciel moderne.

C'est là qu'intervient le CSS. Proposé par Håkon Wium Lie en 1994 et développé avec Bert Bos au W3C, le CSS a été conçu pour être un langage de style dédié. Il a permis aux développeurs d'écrire un ensemble unique de règles dans un fichier séparé (une « feuille de style ») qui pouvait s'appliquer à un site web entier. Changez une ligne de CSS, et voilà, chaque titre sur un millier de pages devient bleu. Cette séparation a rendu les sites web considérablement plus faciles à construire, à mettre à jour et à maintenir. Elle a également permis des designs plus riches, une meilleure accessibilité et des pages qui se chargent plus rapidement en gardant un HTML léger et propre.

Comment ça marche sous le capot

Quand votre navigateur charge une page web, il ne se contente pas de plaquer des pixels sur l'écran au petit bonheur la chance. Il exécute une danse complexe entre votre HTML et votre CSS, en suivant une série d'étapes très précises.

### Le pipeline de rendu : du code aux pixels

  1. Analyse du HTML : Le navigateur lit d'abord le fichier HTML et construit le Document Object Model (DOM). Le DOM est une structure en arbre qui représente tous les éléments de la page — un <h1>, un <p>, un <div>, etc. L'élément <html> est la racine, et tout le reste en découle.

  2. Analyse du CSS : Simultanément, le navigateur récupère et analyse tout le CSS qu'il peut trouver — dans les balises <link>, les blocs <style>, et même les attributs style en ligne. Il construit une structure en arbre similaire appelée le CSS Object Model (CSSOM). Cet arbre associe les sélecteurs à leurs règles de style correspondantes.

  3. Création du Render Tree : C'est ici que la magie opère. Le navigateur combine le DOM et le CSSOM pour créer le Render Tree (l'arbre de rendu). Cet arbre ne contient que les nœuds qui seront réellement affichés sur la page. Par exemple, des éléments comme <head> ou des éléments avec display: none; sont élagués de cet arbre car ils n'occupent pas d'espace visuel. Chaque nœud du Render Tree possède à la fois son contenu (du DOM) et ses styles calculés (du CSSOM).

  4. Layout et Paint : Le navigateur effectue ensuite l'étape de « Layout » (ou « Reflow »), calculant la taille et la position exactes de chaque élément dans le Render Tree. Enfin, il « peint » (Paint) les pixels à l'écran, donnant vie à votre magnifique design.

### L'anatomie d'une règle CSS

Une feuille de style n'est qu'une collection de règles. Chaque règle a une structure simple :

selector {
  property: value;
}
  • Sélecteur (Selector) : C'est le « qui ». Il cible le ou les éléments HTML que vous voulez styler. Il peut s'agir d'un simple nom d'élément comme p, d'une classe comme .user-card, d'un ID comme #main-header, ou d'une combinaison complexe qui cible les éléments en fonction de leurs attributs ou de leur position dans le DOM.
  • Bloc de déclaration : La partie entre les accolades {}. Il contient une ou plusieurs déclarations.
  • Propriété (Property) : Le « quoi ». C'est l'aspect visuel que vous voulez changer, comme color, font-size, ou background-image.
  • Valeur (Value) : Le « comment ». C'est le réglage que vous voulez appliquer à la propriété, comme red, 16px, ou url('cat.gif').

### Le « C » de CSS : le match en cage de la cascade

Que se passe-t-il si deux règles différentes ciblent le même élément ? Par exemple :

#main-title { color: blue; }
h1 { color: red; }

Si vous avez un élément <h1 id="main-title">...</h1>, sera-t-il bleu ou rouge ? C'est là qu'intervient la partie « Cascade » du CSS. C'est un algorithme bien défini — un vrai match en cage — pour résoudre ces conflits. Le gagnant est déterminé par une hiérarchie de trois facteurs :

  1. L'importance (Importance) : Une déclaration marquée avec !important l'emporte sur presque tout le reste. C'est un outil un peu bourrin qui doit être utilisé avec parcimonie. h1 { color: red !important; } battrait la règle bleue.
  2. La spécificité (Specificity) : C'est l'épreuve reine. Le navigateur calcule un score pour chaque sélecteur afin de déterminer lequel est le plus spécifique. Plus le score est élevé, plus son poids est important.
  3. L'ordre de la source (Source Order) : Si deux sélecteurs ont exactement la même importance et la même spécificité, celui qui apparaît plus tard dans le fichier CSS (ou qui est chargé plus tard) gagne. Le dernier arrivé remporte le gros lot.

La spécificité elle-même est calculée en fonction des composants du sélecteur. Vous pouvez y penser comme à un score, souvent représenté par (A, B, C) :

Type de sélecteur Ce qu'il cible Valeur de spécificité (A, B, C) Exemple
ID Un élément avec un id spécifique (1, 0, 0) #nav
Classe / Attribut /
Pseudo-classe		 Éléments avec une classe, un attribut,
ou un état		 (0, 1, 0) .btn, [type="submit"],
:hover
Élément /
Pseudo-élément		 Éléments d'un certain type,
ou une partie de l'un		 (0, 0, 1) h1, p,
::before

Dans notre exemple, #main-title est un sélecteur d'ID (1,0,0) et h1 est un sélecteur d'élément (0,0,1). Le sélecteur d'ID est bien plus spécifique, donc le titre sera bleu.

Histoires vécues

### L'affaire du bouton impossible à déplacer

Une développeuse junior, Maya, devait décaler un bouton « S'inscrire » de 20 pixels vers la droite. Facile, pensa-t-elle. Elle ajouta une classe .nudge-right { margin-left: 20px; } au bouton. Elle rechargea la page. Rien. Le bouton ne bougeait pas. Perplexe, elle ouvrit les outils de développement du navigateur et inspecta le bouton. Elle vit que son style .nudge-right était bien là, mais il était barré. Au-dessus, une autre règle était active : #sidebar .button-group > .btn { margin-left: 0; }. Cette règle, provenant du framework CSS tiers du site, avait un ID, une classe et un sélecteur d'élément. Son score de spécificité était bien plus élevé que celui de son simple sélecteur de classe. Elle ne pouvait pas modifier le framework, alors elle écrivit un sélecteur plus spécifique : #sidebar .button-group > .btn.nudge-right { margin-left: 20px; }. Ça a marché. Leçon : Vos styles n'existent pas dans le vide. Utilisez toujours les outils de développement de votre navigateur pour inspecter les « styles calculés » et comprendre les batailles de spécificité qui se déroulent déjà sur la page.

### L'incident !important

L'équipe était à quelques heures d'un lancement de produit majeur lorsqu'un responsable remarqua qu'un lien dans le pied de page n'avait pas la bonne couleur. Dans la précipitation, un développeur, Ben, n'arrivait pas à comprendre laquelle des dix feuilles de style surchargeait sa correction. Sous pression, il choisit l'option nucléaire : a.footer-link { color: #f0f0f0 !important; }. Ça a marché. Le lancement fut un succès. Six mois plus tard, une nouvelle campagne marketing exigeait que ce même lien soit orange vif. Une autre développeuse passa une demi-journée à essayer de le changer, écrivant des sélecteurs de plus en plus spécifiques sans aucun effet. Elle finit par trouver le !important de Ben, soupira, et fut forcée d'ajouter sa propre règle !important avec une spécificité plus élevée pour surcharger sa surcharge. Leçon : !important est un « code smell ». Il brise la cascade naturelle et crée de la dette technique. C'est le signe que vous ne comprenez pas le CSS existant, et cela rend la maintenance future cauchemardesque. Ne l'utilisez qu'en dernier recours pour surcharger des styles en ligne que vous ne pouvez pas contrôler.

Erreurs et pièges courants

  • Les guerres de spécificité : Écrire des sélecteurs beaucoup trop spécifiques, comme div#main section.content > article.post:first-child h2. Cela rend le CSS rigide et difficile à surcharger. Visez le sélecteur le moins spécifique possible qui fait quand même le travail. Généralement, une seule classe bien nommée est la meilleure solution.
  • Oublier le modèle de boîtes (box model) : Par défaut, les propriétés width et height d'un élément ne s'appliquent qu'à la boîte de contenu. Le padding et le border sont ajoutés en plus, ce qui peut entraîner des décalages de mise en page inattendus. Utilisez box-sizing: border-box; sur vos éléments pour que width et height incluent le padding et la bordure, ce qui est beaucoup plus intuitif.
  • Ne pas utiliser d'unités relatives : Utiliser des pixels (px) pour tout, en particulier les tailles de police, peut causer des problèmes d'accessibilité pour les utilisateurs qui ont besoin d'agrandir le texte. Utilisez des unités relatives comme rem (relative à la taille de police de l'élément racine <html>) pour les polices et les espacements afin de créer des designs plus flexibles et accessibles.
  • Ignorer l'héritage : Certaines propriétés CSS, comme color et font-family, sont héritées par les éléments enfants de leurs parents. D'autres, comme margin, padding, et border, ne le sont pas. Ignorer cette différence peut vous amener à écrire du CSS redondant ou à vous demander pourquoi un élément a un style que vous ne lui avez jamais explicitement appliqué.

Pourquoi ça doit être sur votre radar

Si vous touchez au web de près ou de loin, vous devez comprendre le CSS.

  • Pour les développeurs front-end, c'est votre principal moyen d'expression. La maîtrise du CSS est ce qui sépare un bon développeur d'un excellent.
  • Pour les développeurs back-end, connaître les bases vous aide à générer un HTML plus propre et à collaborer plus efficacement avec vos collègues du front-end. Vous comprendrez pourquoi ils demandent des noms de classe ou des structures de balisage spécifiques.
  • Pour les designers UI/UX, comprendre le médium pour lequel vous concevez est essentiel. Connaître les possibilités et les limites du CSS (comme Flexbox, Grid et les container queries) vous permet de créer des designs qui sont non seulement beaux, mais aussi réalisables et robustes.
  • Pour les chefs de produit et les créateurs de contenu, une compréhension de base du CSS vous aide à comprendre l'effort requis pour apporter des modifications et vous permet de communiquer plus clairement avec votre équipe de développement.

Le CSS est l'un des trois piliers fondateurs du web ouvert, aux côtés du HTML et du JavaScript. Il ne s'agit pas juste de rendre les choses jolies ; il s'agit de créer de la structure, du sens et de l'accessibilité dans la présentation visuelle de l'information.

Pour aller plus loin

Théorie bouclée. Place à la pratique — 100 % dans ton navigateur.

Essayer l'outil: Visionneuse CSS