CSS 1 — modèle de boîte & flexbox

Tu écris du style tous les jours avec NativeWind — mais derrière chaque classe p-4 ou flex-row se cache du CSS, le vrai. Les tests techniques de stage exigent très souvent du CSS vanilla, sans Tailwind ni framework : il faut savoir lire une feuille de style, expliquer le modèle de boîte, et centrer une div sans chercher sur Google. Ce module pose ces fondations en s'appuyant en permanence sur ce que tu connais déjà côté React Native.

Ce que « cascade » veut dire : plusieurs règles se disputent un élément

CSS signifie Cascading Style Sheets, et le mot qui fait la personnalité du langage est cascade. Le problème qu'elle résout : sur une page réelle, un même élément est presque toujours visé par plusieurs règles. Le style par défaut du navigateur dit que les liens sont bleus et soulignés, ta feuille dit qu'ils sont verts, une règle plus bas dit que les liens dans le menu sont blancs. Trois règles, un lien : qui gagne ? La cascade est l'algorithme qui tranche, et il tranche toujours, de façon déterministe. Quand un style « ne marche pas », il n'y a pas de mystère — une autre règle a gagné la dispute, et on peut trouver laquelle.

L'arbitrage se joue en trois temps. Un — l'origine : les styles par défaut du navigateur (c'est pour ça qu'un <h1> est gros et gras sans qu'on l'ait demandé) passent derrière ceux que toi tu écris. Deux — la spécificité : entre deux de tes règles, la plus « précise » gagne. Trois — l'ordre d'apparition : à spécificité égale, la règle écrite en dernier l'emporte. Ce dernier point devrait te rappeler quelque chose : c'est la règle « la dernière classe gagne » de tailwind-merge, vue dans le guide Halterofit — twMerge imite en JavaScript ce que la cascade fait nativement.

La spécificité, maintenant. On la présente souvent avec une arithmétique obscure de points ; la version simple suffit pour lire du CSS et répondre en entrevue. Quatre niveaux de poids, du plus lourd au plus léger :

1. Le style inline — écrit directement sur l'élément, <div style="color: red">. Il bat tout le reste (hors cas exotiques).
2. L'id — le sélecteur #header. Un id est unique dans la page, donc une règle sur un id est très ciblée : elle pèse lourd.
3. La classe — le sélecteur .card. Moins ciblée qu'un id (une classe peut être posée sur cent éléments), donc moins lourde.
4. L'élément — le sélecteur p ou a, qui vise tous les paragraphes ou tous les liens. Le plus générique, donc le plus léger.

L'intuition à garder : plus un sélecteur est ciblé, plus il gagne, et un sélecteur composé cumule — .menu .lien (deux classes) bat .lien (une classe). C'est tout ce qu'il faut pour lire 99 % des feuilles de style réelles.

Dernière chose, et elle explique beaucoup de CSS moderne : les développeurs s'en tiennent presque exclusivement aux classes. Les ids et le style inline sont des armes trop lourdes — une fois qu'une règle #header existe, la surcharger demande un sélecteur encore plus lourd, puis un autre, et la feuille devient une course à l'armement (avec au bout le tristement célèbre !important, qui force une règle à gagner et rend le fichier ingérable). En restant sur des classes, tout le monde joue dans la même catégorie de poids et c'est l'ordre d'écriture, simple et prévisible, qui départage. Tailwind pousse la logique à l'extrême : que des classes, jamais d'id, jamais d'inline.

#promo .carte .titre { color: gray; }

.encart .carte .titre.actif { color: #2563eb; }

Les sélecteurs essentiels, en lecture

Une règle CSS a toujours la même anatomie : un sélecteur (qui est visé ?), puis un bloc de déclarations entre accolades, chacune une paire propriété: valeur;. L'objectif ici n'est pas de réciter tous les sélecteurs — il y en a des dizaines — mais de savoir lire ceux qui couvrent l'immense majorité des feuilles réelles :

/* Élément : « tous les paragraphes » */
p { line-height: 1.6; }

/* Classe : « tout élément portant class="card" » — LE sélecteur du quotidien */
.card { border-radius: 8px; }

/* Id : « L'élément portant id="header" » — rare dans le CSS moderne */
#header { position: sticky; }

/* Descendant (un ESPACE) : « les .prix qui sont QUELQUE PART dans une .card,
   enfant, petit-enfant, peu importe la profondeur » */
.card .prix { font-weight: 700; }

/* Enfant direct (un CHEVRON) : « les li directement enfants du .menu,
   pas les li imbriqués plus profond » */
.menu > li { padding: 8px; }

/* États : au survol de la souris, au focus clavier */
.bouton:hover { background: #0f766e; }
.champ:focus { outline: 2px solid #0f766e; }

Six formes de sélecteurs. Si tu sais lire ça, tu sais lire l'essentiel de n'importe quelle feuille de style.

Trois précisions de lecture. D'abord l'espace contre le chevron : a b (descendant) ratisse large — n'importe quel b à n'importe quelle profondeur sous un a — tandis que a > b (enfant direct) ne vise que le premier niveau. Quand un style semble « traverser » toute une sous-arborescence, cherche un sélecteur descendant.

Ensuite les pseudo-classes comme :hover et :focus : le deux-points signale un état, pas un élément différent. .bouton:hover se lit « le .bouton, quand la souris est dessus » ; :focus, « quand il a le focus clavier » — tu as vu son importance pour l'accessibilité au module précédent. Note qu'un état de survol n'existe pas en mobile natif : il n'y a pas de souris.

Enfin les sélecteurs à double deux-points, ::before et ::after : des pseudo-éléments, un contenu fantôme que CSS insère avant ou après le contenu réel, typiquement pour une décoration (puce maison, trait, icône) sans ajouter de balise. En lecture, .lien::before { content: '→'; } se comprend « CSS dessine une flèche juste avant le texte du lien ». Tu n'as pas besoin d'en écrire, juste de ne pas être dérouté en en voyant.

a { color: #2563eb; }
.menu a { color: white; text-decoration: none; }
.menu > li:hover { background: #1e293b; }

Le modèle de boîte : content, padding, border, margin

Question d'entrevue numéro un du CSS, et à juste titre : c'est la fondation de tout le reste. Chaque élément d'une page — chaque paragraphe, chaque image, chaque div — est rendu comme un rectangle, et ce rectangle a quatre couches concentriques, de l'intérieur vers l'extérieur :

1. Le contenu (content) : le texte, l'image, ce qu'il y a dedans.
2. Le padding : la marge intérieure, l'espace entre le contenu et la bordure. Il porte la couleur de fond de l'élément — un fond coloré s'étend jusque sous le padding.
3. La bordure (border) : le trait qui entoure, avec une épaisseur, un style et une couleur.
4. La margin : la marge extérieure, l'espace entre cette boîte et ses voisines. Elle est toujours transparente — c'est du vide entre les boîtes.

L'analogie classique est le tableau encadré : le contenu est la toile, le padding le passe-partout, la bordure le cadre, la margin l'espace entre deux tableaux sur le mur. Cette distinction te sert déjà en React Native — même modèle, mêmes noms.

Le piège historique que RN n'a pas tient à une question : « quand j'écris width: 180px, qu'est-ce qui mesure 180 pixels ? » Le comportement d'origine, content-box, répond le contenu seul : padding et bordure s'ajoutent par-dessus. Une carte à width: 180px avec padding: 18px et une bordure de 3 px occupe en réalité 180 + 18 + 18 + 3 + 3 = 222 pixels. Personne ne raisonne comme ça : quand tu dis « cette carte fait 180 px », tu penses au rectangle visible. Ce décalage a causé des années de mises en page cassées au pixel près.

La solution universellement adoptée : box-sizing: border-box. Avec elle, width: 180px mesure le rectangle visible, bordure comprise — le contenu se comprime pour laisser la place au padding et à la bordure à l'intérieur. C'est le comportement intuitif, d'où le « reset » qui ouvre pratiquement tous les projets web (quelques règles en tête de feuille pour neutraliser des défauts gênants du navigateur) :

/* Le reset le plus répandu du web : TOUT passe en border-box.
   L'étoile * sélectionne tous les éléments. */
*, *::before, *::after {
  box-sizing: border-box;
}

Trois lignes présentes au sommet de presque toutes les feuilles de style du monde. Quand tu lis un CSS de test technique, pars du principe qu'elles y sont — et vérifie.

.intro    { margin-bottom: 32px; }
.services { margin-top: 16px; }

display : block, inline, et le flux normal du document

Voici, conceptuellement, la plus grosse différence entre le web et React Native. En RN, aucune question à se poser : toute View est positionnée par flexbox, toujours. Sur le web, avant même que flexbox n'entre en scène, les éléments sont posés par le flux normal du document — l'algorithme de mise en page par défaut, hérité de l'époque où une page web était littéralement une page de texte. Le comportement de chaque élément dans ce flux dépend de sa propriété display.

display: block : l'élément se comporte comme un paragraphe — il prend toute la largeur disponible et force un retour à la ligne avant et après, si bien que les blocs s'empilent verticalement. <div>, <p>, <h1>, <section>, <ul> sont des blocs, et acceptent width, height et marges verticales.

display: inline : l'élément se comporte comme un mot dans une phrase. Il se glisse dans le fil du texte, ne provoque aucun retour à la ligne, et — piège classique — ignore width, height et les marges verticales : on ne donne pas une hauteur à un mot au milieu d'une phrase. <a>, <span>, <strong>, <code> sont inline par défaut.

display: inline-block : l'hybride — dans le fil du texte comme un mot, mais acceptant largeur, hauteur et marges. Très utilisé pour les boutons et menus horizontaux avant flexbox ; aujourd'hui surtout croisé dans du vieux code. Et display: none : l'élément disparaît complètement, n'occupe plus aucune place, comme s'il n'était pas dans le HTML — à distinguer de visibility: hidden (invisible mais l'espace reste réservé) et, côté React, du rendu conditionnel condition && <Composant /> qui retire carrément l'élément de l'arbre.

Pourquoi cette taxonomie alors que « tout le monde utilise flexbox » ? D'abord parce que le flux normal reste le défaut : tant que personne n'a écrit display: flex, c'est lui qui commande, et une page de contenu textuel se met très bien en page avec lui seul. Ensuite parce qu'il explique des comportements qui semblent aléatoires quand on vient du mobile : « pourquoi ma div prend toute la largeur ? » (c'est un bloc), « pourquoi mon width est ignoré ? » (c'est un inline), « pourquoi ces images ont un espace mystérieux entre elles ? » (elles sont inline, donc traitées comme des mots séparés par des espaces). Le dev qui connaît display lit ces situations en une seconde ; l'autre ajoute des règles au hasard.

<p>Consultation générale <span class="badge">Populaire</span></p>

.badge {
  width: 80px;
  height: 24px;
  margin-top: 12px;
  padding: 0 8px;
  background: #fde68a;
}

Flexbox : le conteneur range, les enfants négocient

On arrive en terrain connu : chaque flex-row, chaque items-center, chaque justify-between de NativeWind, c'est du flexbox. Le principe, pour le redire proprement une fois : on pose display: flex sur un conteneur, et ses enfants directs deviennent des « items flexibles » rangés le long d'un axe. Les propriétés se répartissent en deux familles selon où on les écrit — c'est la seule chose à ne jamais confondre, et le tableau te la donne d'un coup d'œil.

Le moyen mnémotechnique qui sert depuis quinze ans : justify = l'axe principal, align = l'axe croisé. En row, justify gère l'horizontal et align le vertical ; en column, c'est l'inverse. Tu connais déjà cette gymnastique par NativeWind, elle est identique.

Trois choses méritent en revanche plus qu'une ligne de tableau, parce que ce sont elles qui te feront trébucher. La première : les défauts opposés. Le défaut web de flex-direction est row, celui de React Native est column — même moteur, choix inverses. Le web a choisi row parce que flexbox y a d'abord servi à faire des barres de navigation ; RN a choisi column parce qu'un écran de téléphone est une colonne. Conséquence concrète : le réflexe d'écrire flex-row pour mettre en ligne, oublie-le en CSS vanilla — display: flex tout seul met déjà en ligne. C'est la colonne qu'il faut demander.

La deuxième : flex-shrink. Sur le web il vaut 1, donc un enfant accepte de rétrécir quand la place manque ; en React Native il vaut 0, donc l'enfant déborde plutôt que de céder. Même code, deux rendus — et c'est presque toujours la cause quand un layout se comporte « bizarrement » en passant d'une plateforme à l'autre. La troisième, min-width: 0, a droit à son aparté un peu plus bas : c'est le plancher caché qui empêche flex-shrink de faire son travail.

Un mot d'expérience vécue, tant qu'on est sur flex: 1 : tu as déjà rencontré côté mobile le gotcha du flex-1 qui « s'effondre » — un enfant mesuré à zéro dans un parent sans hauteur contrainte. Le principe vaut des deux côtés : flex: 1 distribue l'espace disponible ; si le parent n'a pas de taille définie sur cet axe, il n'y a rien à distribuer. Quand un flex: 1 ne marche pas, remonte d'un cran : c'est presque toujours le parent.

Visualisons avec l'app fil rouge. La page d'accueil de RendezVous montre trois cartes de services — « Consultation », « Vaccination », « Prise de sang » — alignées en une rangée régulière, chacune de même hauteur, avec un espace constant entre elles. En CSS vanilla, tout tient en une règle sur le conteneur :

.services {
  display: flex;        /* les enfants directs passent en mode flex        */
  /* pas de flex-direction : le défaut web est ROW → déjà en rangée        */
  gap: 16px;            /* 16px entre chaque carte, ni avant ni après      */
  align-items: stretch; /* toutes les cartes prennent la hauteur de la     */
}                       /* plus grande — c'est le défaut, écrit pour lire  */

.services .carte {
  padding: 16px;
  border: 1px solid #e2e8f0;
  border-radius: 8px;
}

Une rangée de cartes : quatre lignes sur le conteneur. Remarque ce qu'on n'a PAS écrit : aucun flex-direction (row est le défaut) et aucune marge sur les cartes (gap s'en charge).

.barre {
  display: flex;
  align-items: center;
  gap: 12px;
}
.barre .date    { flex-shrink: 0; }  /* ex. « mardi 12 mars »          */
.barre .service { flex: 1; }         /* ex. « Consultation de suivi… » */
.barre .bouton  { flex-shrink: 0; }

.page {
  display: flex;
  flex-direction: column;
}
.page__contenu { flex: 1; }   /* censé absorber l'espace restant */
.page__pied    { padding: 16px; }

Centrer, enfin

« Comment centre-t-on une div ? » est une vraie question d'entrevue, et la réponse tient en deux formules — pas une de plus.

Formule 1 — le centrage flex, pour centrer le contenu d'un conteneur, horizontalement et verticalement à la fois :

.parent {
  display: flex;
  justify-content: center; /* centre sur l'axe principal (horizontal en row) */
  align-items: center;     /* centre sur l'axe croisé (vertical en row)      */
}

Le centrage parfait en trois déclarations sur le parent. Seule condition : que le parent ait une hauteur — on ne peut pas centrer verticalement dans un conteneur qui épouse son contenu.

Formule 2 — margin: auto, pour centrer un bloc dans la page. Sur un élément de type bloc dont la largeur est bornée — par un width, ou par un max-width comme dans l'exemple ci-dessous —, margin-left: auto et margin-right: auto signifient « répartissez l'espace restant équitablement des deux côtés » — donc centrage horizontal. C'est le patron immémorial du contenu de page :

.page {
  max-width: 720px; /* jamais plus large que ça (confort de lecture) */
  margin: 0 auto;   /* 0 en vertical, auto = centrage en horizontal  */
}

Le duo max-width + margin: 0 auto : la colonne de contenu centrée qu'on retrouve sur pratiquement tous les sites, celui-ci compris.

Comment choisir ? Question de point de vue : le centrage flex se déclare sur le parent (« centre tout ce que je contiens ») ; le margin: auto se déclare sur l'enfant (« centre-moi dans l'espace qu'on me donne ») et ne fait que l'horizontal. En pratique : contenu de page → formule 2 ; tout le reste (icône dans un bouton, spinner, texte dans une pastille) → formule 1. Détail utile en entrevue : dans un conteneur flex, les marges auto absorbent l'espace libre dans toutes les directions, donc margin: auto sur un enfant flex unique le centre parfaitement.

.row {
  display: flex;                  /* passe les enfants en flexbox        */
  align-items: center;            /* alignés verticalement au centre     */
  justify-content: space-between; /* premiers/derniers aux bords,        */
  gap: 12px;                      /* espace régulier entre les enfants   */
}

.pastille {
  display: flex;
  flex-direction: column;
  justify-content: center;
  width: 200px;
  height: 200px;
}

Lire le CSS de quelqu'un d'autre

Dernière compétence du module, et la plus rentable pour un test technique ou un premier jour de stage : ouvrir une feuille de style écrite par quelqu'un d'autre et s'y orienter vite. Un fichier réel fait des centaines de lignes ; on ne le lit pas de haut en bas. Stratégie en quatre temps.

1. Repère le reset et les fondations, tout en haut : le box-sizing: border-box et les règles sur body (police, couleurs). Elles donnent l'ambiance et les valeurs héritées partout — car certaines propriétés (color, font-family, line-height) s'héritent : posées sur body, elles ruissellent sur tous les descendants qui ne les redéfinissent pas. D'où une seule règle qui typographie toute la page.
2. Identifie les classes « racines » qui structurent la page — .layout, .sidebar, .content… généralement les premiers grands blocs après le reset, souvent des conteneurs flex. Elles donnent le squelette ; le reste est du remplissage.
3. Suis une classe à la trace : Ctrl+F sur .carte et lis toutes ses occurrences — la règle de base, mais aussi .carte:hover ou un .services .carte qui la surcharge. Le style final d'un élément est la somme arbitrée de toutes les règles qui le visent, jamais une seule.
4. Vérifie dans le navigateur, pas dans ta tête : clic droit → « Inspecter » → panneau Styles des DevTools. Il liste toutes les règles qui visent l'élément, de la plus forte à la plus faible, et barre les déclarations perdantes — tu vois l'arbitrage. L'onglet « Computed » dessine même le modèle de boîte avec ses valeurs réelles. Bonus : tu peux modifier les valeurs en direct (un rechargement efface tout) — quand tu te demandes « à quoi sert cette règle ? », désactive-la et regarde ce qui bouge. C'est le meilleur outil d'apprentissage du CSS qui existe.

.carte {
  width: 320px;
  padding: 16px;
  border: 2px solid #e2e8f0;
  margin: 0 12px;
}