CSS 2 — grid, responsive, variables

Dans le module précédent (le modèle de boîte & flexbox), tu as appris à aligner des boîtes le long d'une ligne. Ce module ajoute les trois outils qui font le reste d'une vraie mise en page moderne : grid pour poser une grille en deux dimensions, le responsive pour que la page s'adapte du téléphone à l'écran géant, et les variables CSS pour ranger couleurs et tailles à un seul endroit — exactement comme les design tokens de ton app mobile.

Grid : la deuxième dimension

Flexbox est un outil unidimensionnel : un conteneur, une direction, des enfants alignés le long de cet axe unique. Parfait pour une barre de navigation ou une ligne « icône + texte + badge ». Mais dès qu'on veut un quadrillage — trois cartes par rangée, alignées horizontalement et verticalement — flexbox rame : on peut le forcer avec flex-wrap et des largeurs calculées à la main, mais chaque rangée reste indépendante des autres, et rien ne garantit que les colonnes s'alignent.

CSS Grid est l'outil pensé pour ce cas. L'idée en une phrase : sur le conteneur, tu déclares une grille — combien de colonnes, quelles largeurs — et les enfants se rangent dans les cases, rangée après rangée. Le parent décide de la structure, les enfants la remplissent : un renversement par rapport à flexbox, où les enfants gardent l'initiative sur leur taille.

Deux propriétés suffisent pour démarrer. display: grid transforme le conteneur en grille ; grid-template-columns décrit les colonnes — une largeur par colonne, et le nombre de valeurs donne le nombre de colonnes. Exemple sur la page d'accueil de RendezVous, la clinique fictive du guide, et sa grille de cartes de services :

/* Le conteneur des cartes de services devient une grille de 3 colonnes. */
.services {
  display: grid;                        /* j'active le mode grille */
  grid-template-columns: 1fr 1fr 1fr;   /* 3 colonnes de largeur égale */
  gap: 16px;                            /* l'espace ENTRE les cases (lignes ET colonnes) */
}
/* Les enfants (.service-card) n'ont RIEN à déclarer :
   ils se rangent tout seuls dans les cases, de gauche à droite,
   puis passent à la rangée suivante. */

Trois lignes de CSS sur le parent, zéro ligne sur les enfants : c'est la signature de grid.

Arrête-toi sur cette unité étrange : fr, pour fraction — une part de l'espace libre. 1fr 1fr 1fr découpe l'espace disponible en trois parts égales, et on peut mélanger : 200px 1fr donne une colonne fixe (une barre latérale) et une colonne qui prend tout le reste ; 2fr 1fr donne une première colonne deux fois plus large. Tu reconnais l'esprit de flex: 1 — distribuer l'espace restant par parts — mais déclaré sur le parent, colonne par colonne. Dernier raccourci : repeat(4, 1fr) dit la même chose que 1fr 1fr 1fr 1fr. Du confort seulement… jusqu'à la section suivante, où repeat() révèle un super-pouvoir.

.services {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
  gap: 16px;
}

<section class="services">
  <div class="services__interieur">
    <article class="service-card">…</article>
    <article class="service-card">…</article>
    <!-- … sept autres cartes … -->
  </div>
</section>

La grille responsive sans media query : la formule du module

La grille à trois colonnes de RendezVous a un défaut évident : sur un téléphone, trois colonnes dans 360 pixels donnent des cartes écrasées. Le réflexe classique serait une media query — un bloc de style qui ne s'applique qu'à partir (ou en dessous) d'une certaine largeur d'écran ; on les détaille deux sections plus bas. Mais grid offre plus élégant : une grille qui calcule elle-même son nombre de colonnes. Une seule ligne, probablement celle que tu recroiseras le plus souvent dans du vrai code — décortiquons-la.

grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));

Lis-la de l'intérieur vers l'extérieur. minmax(240px, 1fr) décrit une colonne élastique : « jamais plus étroite que 240 pixels, et sinon, prends une part égale de l'espace libre (1fr) ». Le minimum garantit la lisibilité — une carte de service ne descendra jamais sous 240 px — et le maximum en fr garantit que les colonnes se partagent équitablement toute la largeur, sans laisser de vide à droite.

auto-fit remplace le nombre fixe dans repeat() : au lieu de « répète 3 fois », « répète autant de fois que la place le permet ». Le navigateur calcule en continu — conteneur de 1000 px ? quatre colonnes (élargies à 250 px pour remplir) ; fenêtre à 700 px ? deux ; téléphone de 360 px ? une seule, pleine largeur. Les cartes passent de 4 à 3 à 2 à 1 toutes seules, sans un seul seuil écrit.

Un mot sur son jumeau, que tu croiseras autant : auto-fill. Les deux créent autant de colonnes que la place le permet, mais ils ne font pas la même chose des colonnes vides. auto-fill les garde — elles occupent leur largeur, invisibles, et les cartes présentes restent à leur taille minimale. auto-fit les effondre à zéro, et les cartes présentes s'étirent pour occuper toute la ligne. La différence ne se voit donc que lorsqu'il y a moins de cartes que de colonnes possibles : à six cartes dans une grille qui en tient quatre par ligne, les deux mots-clés donnent exactement la même page. C'est ce qui les rend faciles à confondre — et c'est aussi la réponse à « pourquoi mes deux cartes restent-elles serrées à gauche au lieu de remplir la ligne ? ». Le coupable est auto-fill ; le remède est auto-fit.

Mesure ce qui vient de se passer : tu as décrit une contrainte (« chaque carte a besoin d'au moins 240 px ») et le navigateur en a déduit la mise en page, pour toutes les largeurs présentes et futures. C'est la philosophie du CSS moderne — déclarer l'intention, laisser le moteur calculer — poussée au maximum. Beaucoup de grilles de cartes en production n'ont que ça comme stratégie responsive.

.services {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 16px;
}

.slots {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(150px, 1fr));
  gap: 8px;
}

Quand grid, quand flexbox : la règle simple

Question inévitable — on te la posera en entrevue, et tu te la poseras devant chaque mise en page. Une règle simple couvre 90 % des cas :

• Le contenu dicte la disposition → flexbox. Tu as des éléments de tailles naturelles différentes (un logo, trois liens, un bouton) et tu veux juste les aligner le long d'un axe, en laissant chacun prendre sa place ? C'est du flex. La disposition découle du contenu.
• La grille dicte la disposition → grid. Tu as une structure en tête avant de connaître le contenu — « trois colonnes », « une sidebar de 200 px et le reste », « des cartes alignées en quadrillage » — et le contenu devra s'y ranger ? C'est du grid. La disposition précède le contenu.

Autrement dit : flex part des enfants et les aligne ; grid part du parent et les case. Et surtout, ce n'est pas un duel — une vraie page mélange les deux en permanence, souvent l'un dans l'autre. Regarde la page d'accueil de RendezVous :

/* La barre du haut : un logo, des liens, un bouton "Prendre rendez-vous".
   Des éléments de tailles différentes à aligner sur UNE ligne → flexbox. */
.topbar {
  display: flex;
  align-items: center;         /* centrage vertical sur la ligne */
  justify-content: space-between; /* logo à gauche, actions à droite */
}

/* La section des services : un quadrillage de cartes → grid (la formule !). */
.services {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
  gap: 16px;
}

/* Et DANS chaque carte : une icône, un titre, une flèche, sur une ligne → re-flexbox. */
.service-card__entete {
  display: flex;
  align-items: center;
  gap: 8px;
}

Grid pour le quadrillage, flex pour les lignes — y compris des lignes flex à l'intérieur des cases de la grille. C'est l'imbrication normale d'une page réelle.

Au passage, .topbar n'a rien de neuf : c'est La rangée flexible du module CSS 1 — modèle de boîte & flexbox, recopiée telle quelle — display: flex, align-items: center, justify-content: space-between. Mêmes déclarations, même effet. Et .service-card__entete, deux niveaux plus bas, en est une seconde occurrence dans le même fichier, sans le justify-content puisqu'on ne veut rien pousser aux bords.

Un repère pour les cas limites : si tu te surprends à calculer des largeurs en pourcentage sur des enfants flex (width: 33.33%…) pour simuler des colonnes alignées, arrête-toi — tu réinventes grid avec les moyens du bord. Inversement, grid pour poser deux éléments côte à côte sans notion de colonnes est une surcharge : un flex suffisait. Aucun des deux choix ne casse la page, mais choisir l'outil qui correspond à l'intention rend le CSS bien plus lisible — et c'est cette intention qu'un recruteur écoute quand il pose la question.

Le responsive : une page, toutes les largeurs

Le responsive design, c'est l'idée qu'une même page reste utilisable du téléphone (environ 360 px) à l'écran de bureau (1400 px et plus). Ce n'est pas une option : plus de la moitié du trafic web mondial est mobile, et Google indexe les sites d'après leur version mobile. Historiquement on faisait deux sites (le tristement célèbre m.exemple.com) ; depuis les années 2010, une page dont le CSS s'adapte.

Première pièce, discrète mais indispensable : la balise viewport, dans le <head> de chaque page. Tu l'as déjà croisée :

<meta name="viewport" content="width=device-width, initial-scale=1">

Son histoire explique son existence. Quand l'iPhone est sorti, le web était pensé pour des écrans de 1000 px ; pour ne pas afficher des pages cassées, le navigateur mobile faisait semblant d'être large de 980 px puis dézoomait le tout — d'où ces sites minuscules qu'on pinçait pour zoomer. La balise dit : « arrête de faire semblant, utilise la vraie largeur de l'appareil, sans zoom initial ». Sans elle, toutes tes media queries mobiles sont court-circuitées. Si un site « ignore » ton CSS mobile, vérifie cette balise en premier.

Deuxième pièce, la principale : les media queries. Une media query est un bloc de CSS conditionnel : « ces règles ne s'appliquent que si l'écran remplit telle condition ». La condition la plus courante, de très loin, porte sur la largeur :

/* Ces règles s'appliquent TOUT LE TEMPS. */
.rendez-vous__panneau {
  padding: 24px;
}

/* Celles-ci s'appliquent SEULEMENT si la fenêtre fait 600 px de large ou moins. */
@media (max-width: 600px) {
  .rendez-vous__panneau {
    padding: 12px;            /* moins d'espace perdu sur petit écran */
  }
}

max-width: 600px se lit « largeur maximale 600 px », donc : « de 0 à 600 px ». Au-delà, le bloc est ignoré et seule la règle générale s'applique.

Reste une question de stratégie : dans quel sens écrire son CSS ? Le desktop-first écrit d'abord le style grand écran, puis des media queries en max-width qui retirent ou compactent pour les petits écrans. Le mobile-first fait l'inverse : le style de base est celui du téléphone — une colonne, tout simple — et des media queries en min-width ajoutent de la complexité quand la place augmente.

Mobile-first a gagné pour trois raisons. Robustesse : le style par défaut est le plus simple, et c'est lui qui s'applique si une media query échoue. Discipline : partir du mobile force à décider ce qui est essentiel (tout doit tenir dans 360 px) puis à enrichir, là où partir du desktop mène à caser tant bien que mal une page chargée dans un petit écran. Écosystème : Tailwind — donc NativeWind — est mobile-first par construction, puisque md:flex-row veut dire « à partir de la largeur md », un min-width déguisé. Tu pratiques déjà le mobile-first sans le savoir.

.medecins {
  display: grid;
  grid-template-columns: 1fr;   /* base : une colonne */
  gap: 12px;
}

@media (min-width: 700px) {
  .medecins {
    grid-template-columns: 1fr 1fr;
  }
}

@media (min-width: 1100px) {
  .medecins {
    grid-template-columns: repeat(3, 1fr);
    gap: 24px;
  }
}

.medecins {
  display: grid;
  grid-template-columns: 1fr;
}

@media (min-width: 1100px) {
  .medecins { grid-template-columns: repeat(3, 1fr); }
}

@media (min-width: 700px) {
  .medecins { grid-template-columns: 1fr 1fr; }
}

Les unités : px, %, rem, em, vh, vw — quoi utiliser où

Jusqu'ici on a écrit des px partout, mais le CSS offre tout un vocabulaire d'unités, et choisir la bonne fait partie de la lecture d'un code soigné. Pas de dogme — chaque unité a son terrain naturel :

Une seule ligne du tableau mérite un développement, parce que sa raison d'être est humaine et pas technique : rem. Écrire font-size: 1.25rem semble une façon compliquée de dire 20 px… jusqu'au jour où un utilisateur malvoyant règle la taille de police de son navigateur sur « grande ». Tous les rem de ta page grandissent alors proportionnellement, et la page reste lisible ; les tailles en px, elles, ignorent ce réglage — le texte reste petit et l'utilisateur est coincé. D'où une convention professionnelle sans ambiguïté : les tailles de police en rem, par respect pour le réglage de l'utilisateur. C'est un enjeu d'accessibilité, dans la lignée directe du module sur le HTML sémantique.

Les variables CSS : tes design tokens, version navigateur

Tu connais déjà le problème que les variables CSS résolvent, puisque Halterofit le résout tous les jours avec ses constantes de design : une couleur primaire écrite en dur à quarante endroits transforme un changement de charte en chasse au trésor, et une faute de frappe crée un quarante-et-unième bleu presque identique. La réponse est toujours la même — déclarer la valeur une fois, la référencer partout — et le CSS a son mécanisme natif : les custom properties, qu'on appelle couramment variables CSS.

La syntaxe tient en deux moitiés. Déclarer : une propriété dont le nom commence par deux tirets, --couleur-primaire: #2563eb;. Utiliser : la fonction var(). Par convention, les variables globales se déclarent sur :root — la racine du document — pour être visibles partout :

/* Le "fichier de tokens" de RendezVous : toutes les décisions visuelles, ici. */
:root {
  --couleur-primaire: #2563eb;   /* le bleu clinique */
  --couleur-fond: #ffffff;
  --couleur-texte: #1f2937;
  --rayon-carte: 12px;
  --espace-section: 48px;
}

/* Partout ailleurs, on RÉFÉRENCE, on n'écrit plus jamais la valeur. */
.bouton-rdv {
  background: var(--couleur-primaire);
  border-radius: var(--rayon-carte);
}
.service-card {
  background: var(--couleur-fond);
  color: var(--couleur-texte);
  border-radius: var(--rayon-carte);
}

Changer le bleu de la clinique = changer une ligne dans :root. Le reste du fichier n'y touche jamais.

Ce qui les rend puissantes — et différentes d'une simple constante — c'est qu'elles suivent la cascade. Une variable déclarée sur un élément vaut pour cet élément et tout son sous-arbre, et un descendant peut la redéfinir localement. D'où le cas d'usage roi, le thème :

/* Le mode sombre ne restyle RIEN : il redéfinit seulement les variables. */
.theme-sombre {
  --couleur-fond: #111827;
  --couleur-texte: #f9fafb;
  --couleur-primaire: #60a5fa;   /* un bleu plus clair, lisible sur fond sombre */
}
/* Aucune règle de .service-card, .bouton-rdv, etc. à réécrire :
   elles lisent var(--couleur-fond) et trouvent la nouvelle valeur.
   Basculer le thème = ajouter class="theme-sombre" sur <body>. Une ligne de JS. */

Le composant dit « je suis couleur de fond » ; le thème décide ce que « couleur de fond » veut dire aujourd'hui. Les deux ne se connaissent pas.

Note la mécanique, car c'est elle qu'on teste dans les questions pièges : quand le navigateur rencontre var(--couleur-fond), il remonte l'arbre depuis l'élément courant et prend la déclaration la plus proche. Une carte dans un <body class="theme-sombre"> trouve d'abord le #111827, jamais le blanc de :root. Ce mouvement — une valeur déposée en haut, lue par tout le sous-arbre, redéfinissable localement — est le même patron que le contexte React et ses Provider imbriqués, appliqué au style.

:root {
  --accent: #2563eb;
}
.encart-promo {
  --accent: #d97706;          /* orange, pour attirer l'œil */
}
.badge {
  background: var(--accent);
}

<body>
  <span class="badge">Nouveau</span>            <!-- badge A -->
  <div class="encart-promo">
    <span class="badge">-20 %</span>             <!-- badge B -->
  </div>
</body>

Position et empilement : le survol utile

Dernière famille d'outils, à connaître en lecture plus qu'en virtuosité : position, qui sort un élément du flux normal, et z-index, qui gère qui passe devant qui. Tu les croiseras dans tout code réel — badges, menus déroulants, en-têtes collants — et cinq valeurs suffisent pour lire sans trébucher.

• static — le défaut : l'élément suit le flux normal, et top/left/z-index n'ont aucun effet sur lui. Retiens ce dernier point, il alimente le piège en bas de section.
• relative — l'élément reste à sa place dans le flux, mais on peut le décaler (top: 4px…) et surtout il devient le point de repère de ses descendants en absolute. On le pose souvent sans aucun décalage, juste pour ce rôle d'ancre.
• absolute — l'élément sort du flux (les autres font comme s'il n'existait pas) et se positionne par rapport à son ancêtre positionné le plus proche. Duo classique : parent relative, enfant absolute — la pastille de notification sur le coin d'une icône.
• fixed — comme absolute, mais par rapport à la fenêtre : ne bouge pas au défilement. Bannières de cookies, boutons flottants.
• sticky — l'hybride : l'élément défile normalement jusqu'à atteindre le seuil donné (top: 0), puis reste collé. C'est l'en-tête de RendezVous, visible pendant que le patient fait défiler les créneaux.

/* Le duo relative/absolute : la pastille "2" sur la cloche de notifications. */
.cloche {
  position: relative;      /* aucune autre propriété : la cloche sert juste d'ANCRE */
}
.cloche__pastille {
  position: absolute;      /* sortie du flux : elle flotte au-dessus */
  top: -4px;               /* positionnée par rapport à .cloche, l'ancêtre positionné */
  right: -4px;
}

/* L'en-tête collant de la page de prise de rendez-vous. */
.entete-slots {
  position: sticky;
  top: 0;                  /* défile, puis se colle en haut de l'écran */
  z-index: 10;             /* passe DEVANT les créneaux qui défilent dessous */
}

Les deux motifs à reconnaître au premier coup d'œil : l'ancre relative + enfant absolute, et le sticky; top: 0 d'un en-tête collant.

Un mot de plus sur sticky, parce que son échec est silencieux et qu'il coûte des heures. Un élément collant ne se cale pas par rapport à la fenêtre : il se cale par rapport à son conteneur de défilement, et n'importe quel ancêtre dont l'overflow vaut autre chose que visible — un overflow: hidden posé trois niveaux plus haut pour couper un débordement, par exemple — devient ce conteneur. L'élément colle alors à l'intérieur de cet ancêtre, qui bien souvent ne défile pas : à l'écran, il ne colle plus du tout. Ni erreur, ni avertissement. Deux autres conditions se vérifient dans la foulée : le top (ou bottom) est obligatoire — position: sticky tout seul ne fait rien —, et le parent direct doit être plus haut que l'élément, faute de quoi il n'y a aucune distance sur laquelle coller. Quand un en-tête collant refuse de coller, remonte la chaîne des parents à la recherche d'un overflow avant toute autre chose.

Reste z-index : quand deux éléments positionnés se chevauchent, il décide lequel est dessiné devant — plus le nombre est grand, plus l'élément est « proche de toi ». La règle capitale, celle que tout le monde apprend à ses dépens : z-index n'a d'effet que sur un élément positionné (ou dans quelques autres contextes, comme les enfants d'une grille ou d'un flex). Sur un élément resté en static — le défaut ! — il est purement ignoré.

Transitions : le minimum vital pour lire du code réel

Un mot, pour finir, sur une propriété que tu verras dans à peu près chaque feuille de style réelle : transition. Par défaut, un changement de style est instantané — un bouton qui passe de bleu à bleu foncé au survol saute d'une couleur à l'autre. transition demande au navigateur d'animer ce changement : tu déclares quelle(s) propriété(s) surveiller et en combien de temps lisser le passage.

.bouton-rdv {
  background: var(--couleur-primaire);
  transition: background 200ms;   /* propriété à animer + durée */
}
.bouton-rdv:hover {
  background: #1d4ed8;            /* le survol change le fond… */
}
/* …et la transition lisse le passage sur 200 ms, aller ET retour. */

La transition se déclare sur l'état de base, pas sur le :hover : ainsi elle joue dans les deux sens, à l'entrée comme à la sortie du survol.

C'est tout ce qu'il faut pour lire du code : transition: propriété durée, parfois complété d'une courbe d'accélération (ease-out…) et d'un délai. Deux repères de bon goût : des durées courtes (150–300 ms, au-delà l'interface paraît molle), et animer opacity et transform, que le navigateur sait accélérer, plutôt que des propriétés de mise en page comme width. L'animation sérieuse aura son propre guide dans l'Atlas (GSAP, à venir) ; ici on s'arrête au niveau « je comprends ce que fait cette ligne ».