/**
 * Pont entre le moteur de formulaires du blueprint et la charte de ce site.
 *
 * `form.css` n'habille rien tout seul : elle consomme 32 tokens de design qui
 * vivent dans le `tokens.css` du blueprint. Ce site tourne sur `bricks-child`,
 * hors blueprint, donc aucun de ces tokens n'existe — et un `var()` sans valeur
 * ne rend pas une valeur par défaut, il rend RIEN.
 *
 * Mesuré le 09/09/2026 : `form.css` était bien chargée, et le formulaire
 * s'affichait quand même entièrement nu — sans colonne, sans fond de champ,
 * sans rayon, les options en simple texte empilé. Le défaut ne se voit pas dans
 * le HTML (la feuille est là), il ne se voit qu'à l'image.
 *
 * ── Pourquoi il y a aussi des surcharges de règles ──────────────────────────
 *
 * Les tokens supposent un thème CLAIR : `.c-form__control` et `.c-form__choice`
 * prennent `--color-surface-page` comme fond, c'est-à-dire la surface de la
 * page. Or ce site est sombre et ses champs sont clairs — relevé sur le rendu
 * Heyflow : page `#1a1b23`, pavés `#fafafa`, rayon 8 px, hauteur 56 px.
 *
 * On pourrait faire dire à `--color-surface-page` la couleur des champs. Ce
 * serait un token qui ment, et le prochain à le lire y perdrait son temps. Les
 * tokens gardent donc des valeurs honnêtes, et les trois endroits où le schéma
 * clair-sur-sombre diffère sont surchargés explicitement, plus bas.
 *
 * Valeurs relevées sur le rendu réel, jamais déduites du CSS.
 */

body.brx-body {
  /* ── Surfaces ─────────────────────────────────────────────────────────── */
  /* La page, telle que la sert Bricks. */
  --color-surface-page: #1a1b23;
  /* Les champs et les options : clairs, posés sur la page sombre. */
  --color-surface-sunken: #fafafa;

  /* ── Textes ───────────────────────────────────────────────────────────── */
  /* Sur un champ clair : c'est la couleur de ce qu'on saisit. */
  --color-text-base: #1a1b23;
  --color-text-strong: #1a1b23;
  /* Les aides et le compteur d'étapes vivent sur la page sombre. */
  --color-text-muted: rgba(255, 255, 255, 0.62);

  /* ── Bordures ─────────────────────────────────────────────────────────── */
  --color-border-base: rgba(26, 27, 35, 0.14);
  --color-border-strong: rgba(26, 27, 35, 0.38);
  --color-border-focus: #ecf890;

  /* ── Marque ───────────────────────────────────────────────────────────── */
  /* Le vert-jaune des CTA du site, relevé : rgb(236, 248, 144). */
  --color-brand-50: rgba(236, 248, 144, 0.22);
  --color-brand-100: rgba(236, 248, 144, 0.35);
  --color-brand-300: rgba(236, 248, 144, 0.65);
  --color-brand-500: #ecf890;
  --color-brand-700: #1a1b23;
  --color-feedback-danger: #d92d20;

  /* ── Typographie ──────────────────────────────────────────────────────── */
  /*
   * En PIXELS, et c'est un piège mesuré, pas une préférence.
   *
   * Ce site pose une racine à 62,5 % — convention Bricks — donc `1rem` vaut
   * **10 px**, pas 16. Les tokens écrits en rem divisaient tout par 1,6 : les
   * libellés de question sortaient à 10 px et le bouton d'envoi aussi. Le HTML
   * et le CSS étaient pourtant justes ; seule l'image le montrait.
   *
   * Les libellés sont à 16 px en graisse normale — pas 20/800 : mesuré sur le
   * rendu Heyflow.
   */
  --font-size-s: 16px;
  --font-size-l: 18px;
  /*
   * Consommé par le titre d'écran, arrivé de l'amont le 02/10/2026. Il est
   * masqué sur ce site — Heyflow n'en affichait pas — mais le token est quand
   * même dit : le repli de `form.css` vaut `1.5rem`, c'est-à-dire **15 px** ici
   * et non 24, à cause de la racine à 62,5 %. Un titre réaffiché sortirait donc
   * plus petit que le texte courant, ce qui ne se verrait qu'à l'image.
   */
  --font-size-xl: 24px;
  --font-weight-regular: 400;
  --font-weight-semibold: 500;
  --font-weight-bold: 500;

  /* ── Formes et profondeur ─────────────────────────────────────────────── */
  --radius-s: 6px;
  --radius-m: 8px;
  --radius-full: 999px;
  --shadow-m: 0 8px 24px rgba(0, 0, 0, 0.28);
  --layer-dropdown: 60;

  /* ── Espacements ──────────────────────────────────────────────────────── */
  --space-3xs: 4px;
  --space-2xs: 8px;
  --space-xs: 12px;
  --space-s: 16px;
  --space-xl: 40px;

  /* ── Mouvement ────────────────────────────────────────────────────────── */
  --motion-duration-fast: 150ms;
  --motion-easing-standard: cubic-bezier(0.2, 0, 0.2, 1);
  --motion-easing-spring: cubic-bezier(0.2, 0.8, 0.2, 1);
}

/* ─────────────────────────────────────────────────────────────────────────
 * Ce que le schéma clair-sur-sombre impose de surcharger.
 * ───────────────────────────────────────────────────────────────────────── */

/*
 * La colonne. Le bloc de code occupe toute la largeur de sa section : sans
 * contrainte, le formulaire s'étale d'un bord à l'autre à 1920 px. La largeur
 * relevée sur le rendu Heyflow est de 720 px, centrée.
 */
/*
 * Deux largeurs, pas une — c'est ce que fait la production.
 *
 * L'accroche y court sur 880 px, le formulaire sur 720. Les enfermer toutes
 * deux dans 720 rétrécissait le texte d'introduction et changeait ses retours à
 * la ligne : c'est l'« en‑tête différent » relevé en recette le 02/10/2026.
 */
#form-container {
  max-inline-size: 880px;
  margin-inline: auto;
}

/*
 * L'accroche, reprise au trait près de la feuille de production — graisse 300
 * et interligne 22 px compris. Elle sortait ici en 15 px / 400, c'est-à-dire
 * l'héritage du corps de page, faute d'être dite.
 */
#form-container .paraph-form {
  color: #fafafa;
  font-size: 16px;
  font-weight: 300;
  line-height: 22px;
  text-align: center;
  margin-block-end: 32px;
}

/* Le formulaire garde sa colonne de 720 px au centre des 880. */
.c-form__form {
  max-inline-size: 720px;
  margin-inline: auto;
}

/*
 * « Prénom » et « Nom » restent sur une ligne, quelle que soit la largeur.
 *
 * `form.css` replie la grille sur une seule colonne sous 768 px — un réglage
 * juste en général, mais qui sépare aussi ces deux champs-là. C'est ce qu'a vu
 * la recette du 06/10/2026 : à 1440 ils sont bien côte à côte, à 768 et en
 * dessous ils s'empilent. Une fenêtre non maximisée suffit à passer sous le
 * seuil.
 *
 * On rend donc ses deux colonnes à la grille. Le geste est sûr parce qu'il ne
 * peut toucher qu'eux : sur les cinq définitions de ce site, « prenom » et
 * « nom » sont les SEULS champs qui ne portent pas `full` — tout le reste
 * traverse la grille de toute façon. Vérifié avant d'écrire cette règle ; si un
 * jour un autre champ perd son `full`, c'est ici qu'il faudra regarder.
 *
 * À 375 px, les deux font 159 px — largement de quoi écrire un prénom.
 */
@media (max-width: 768px) {
  .c-form__grid {
    grid-template-columns: repeat(2, minmax(0, 1fr));
  }
}

/* Les champs et les options sont clairs, la page est sombre. */
.c-form__control,
.c-form__choice {
  background: var(--color-surface-sunken);
  border-color: transparent;
}

/*
 * L'indice d'un champ clair doit être sombre. `--color-text-muted` sert aussi
 * aux aides posées sur la page sombre : les deux ne peuvent pas partager une
 * seule valeur, donc celle-ci est dite ici.
 */
.c-form__control::placeholder,
.c-form__select-button.is-placeholder .c-form__select-value {
  color: rgba(26, 27, 35, 0.5);
}

/*
 * La liste déroulante d'un « select ».
 *
 * `form.css` la peint avec `--color-surface-page` et surligne l'option active
 * avec `--color-surface-sunken` : juste sur un thème CLAIR, où la page est
 * blanche et le surlignage légèrement plus sombre. Ici c'est l'inverse — page
 * sombre, champs clairs — et l'option active sortait donc **blanche sur
 * blanc**, strictement illisible.
 *
 * Relevé le 30/09/2026 en recette : fond `rgb(250,250,250)`, texte
 * `rgb(255,247,239)`. Le HTML et le CSS étaient tous deux corrects ; seule
 * l'image, liste ouverte, le montrait.
 *
 * La liste est donc claire comme le champ fermé dont elle prolonge la surface.
 */
.c-form__select-list {
  background: var(--color-surface-sunken);
  border-color: rgba(26, 27, 35, 0.12);
}

.c-form__select-option {
  color: #1a1b23;
}

.c-form__select-option.is-active,
.c-form__select-option:hover {
  background: rgba(26, 27, 35, 0.08);
}

.c-form__select-option[aria-selected="true"] {
  color: #1a1b23;
  background: var(--color-brand-500);
}

/* Les libellés, le compteur d'étapes et le titre d'écran vivent sur la page. */
.c-form__label,
.c-form__screen-title,
.c-form__step,
.c-form__note,
.c-form__help {
  color: #fff;
}

/*
 * ── Les tailles de texte, relevées sur la production ───────────────────────
 *
 * Recette du 02/10/2026 : « taille des textes encore différents ». Le corps de
 * page de ce site est à 15 px, et tout ce que `form.css` ne dimensionne pas en
 * hérite. Heyflow, lui, pose 16 px partout dans le formulaire — relevé dans son
 * shadow DOM, pas déduit : intitulés et pavés en 16 px / 400 / Poppins.
 *
 * Les valeurs sont donc dites, champ par champ, plutôt que laissées à
 * l'héritage.
 */
.c-form__label {
  font-weight: 400;
  font-size: 16px;
  /* 20,8 px chez Heyflow, soit 1,3 — contre 1,7 hérité du corps de page. */
  line-height: 1.3;
  padding-block-end: 10px;
}

.c-form__choice,
.c-form__choice-text,
.c-form__control,
.c-form__select-button,
.c-form__select-value,
.c-form__select-option {
  font-size: 16px;
}

/*
 * Le même interligne serré que Heyflow, 1,3. Sur un pavé d'une ligne cela ne se
 * voit pas ; dès qu'un intitulé passe à deux lignes — ce qui arrive sur tous
 * les pavés en mobile — l'écart de 27,2 à 20,8 px se lit tout de suite.
 */
.c-form__choice,
.c-form__choice-text {
  line-height: 1.3;
}

/*
 * Tous les champs ont la hauteur d'un pavé.
 *
 * Le bouton du « select » sortait à 49 px là où les pavés font 56 : l'œil
 * attrape la marche, surtout quand les deux se suivent. Heyflow donne 56 px à
 * l'un comme à l'autre.
 */
.c-form__control,
.c-form__select-button {
  min-block-size: 56px;
}

.c-form__step {
  color: var(--color-text-muted);
}

/* ─────────────────────────────────────────────────────────────────────────
 * Ce que Heyflow ne montrait pas.
 *
 * Recette CDP du 30/09/2026, sur les quatre parcours : « est-ce qu'on pourrait
 * reprendre le même design que le Heyflow ? ». Le moteur ajoute trois éléments
 * que le rendu d'origine n'avait pas — un compteur d'étapes, un titre d'écran
 * qui redit la question posée juste en dessous, et un « (optionnel) » accolé au
 * libellé.
 *
 * On les RETIRE DE L'ŒIL, pas du document : masqués par `clip-path`, ils
 * restent lus par les lecteurs d'écran, qui perdraient sinon le seul repère de
 * progression du parcours et l'information qu'un champ est facultatif.
 *
 * Pour en réafficher un, supprimer son sélecteur de la liste ci-dessous — rien
 * d'autre à défaire.
 * ───────────────────────────────────────────────────────────────────────── */
.c-form__step,
.c-form__screen-title,
.c-form__optional {
  position: absolute;
  inline-size: 1px;
  block-size: 1px;
  margin: -1px;
  padding: 0;
  overflow: hidden;
  clip-path: inset(50%);
  white-space: nowrap;
}

/*
 * L'aide passe AU-DESSUS des choix qu'elle commente.
 *
 * Le moteur la place après le groupe d'options, où « Plusieurs réponses
 * possibles. » arrive une fois le choix fait — trop tard pour servir. Elle
 * sortait de surcroît en blanc à 16 px, soit exactement le traitement d'un
 * libellé de question : à l'image, on lisait deux questions.
 *
 * Le champ est déjà `display: flex`, l'ordre suffit donc à la remonter ; le DOM
 * garde sa suite logique, et le lien `aria-describedby` avec lui.
 */
.c-form__field {
  flex-direction: column;
}

.c-form__field > .c-form__label {
  order: 1;
}

.c-form__field > .c-form__help {
  order: 2;
  margin-block: calc(var(--space-3xs) * -1) var(--space-2xs);
  color: var(--color-text-muted);
  font-size: 14px;
}

.c-form__field > .c-form__choices,
.c-form__field > .c-form__select,
.c-form__field > .c-form__control {
  order: 3;
}

.c-form__field > .c-form__error {
  order: 4;
}

/*
 * Les options sont SÉPARÉES, chacune à coins arrondis.
 *
 * `form.css` les fait se toucher pour partager une bordure — c'est juste sur un
 * thème clair à bordures visibles. Le rendu Heyflow, lui, aligne des pavés
 * détachés de 8 px d'écart. On défait donc la bordure commune.
 */
.c-form__choices {
  gap: var(--space-2xs);
}

/*
 * Deux options se mettent côte à côte, comme le fait Heyflow pour un « Oui /
 * Non ». Le compte se lit en CSS : « un deuxième enfant existe, un troisième
 * non ». Au-delà de deux, la colonne reste la bonne réponse — six intitulés de
 * six mots ne tiennent pas sur une ligne.
 */
.c-form__choices:has(.c-form__choice:nth-child(2)):not(:has(.c-form__choice:nth-child(3))) {
  flex-direction: row;
}

.c-form__choices:has(.c-form__choice:nth-child(2)):not(:has(.c-form__choice:nth-child(3))) .c-form__choice {
  flex: 1 1 0;
}

/* En mobile, deux pavés côte à côte deviennent illisibles. */
@media (max-width: 480px) {
  .c-form__choices:has(.c-form__choice:nth-child(2)):not(:has(.c-form__choice:nth-child(3))) {
    flex-direction: column;
  }
}

.c-form__choices .c-form__choice,
.c-form__choices .c-form__choice:first-child,
.c-form__choices .c-form__choice:last-child {
  border-radius: var(--radius-m);
  border-block-start-width: 1px;
  margin-block-start: 0;
}

/*
 * La même remise à 1 px, redite sur le sélecteur voisin de `form.css`.
 *
 * Elle y vaut `.c-form__choices .c-form__choice + .c-form__choice`, soit une
 * classe de plus que la règle ci-dessus : sans ce doublon, l'amont l'emportait
 * et toutes les tuiles sauf la première et la dernière gardaient une bordure
 * haute de 0. Au repos cela ne se voyait pas — la bordure est transparente —
 * mais au survol, où elle prend le vert de marque, le liseré n'entourait la
 * tuile que sur trois côtés. Relevé le 30/09/2026 : tuiles 1 à 4 en « 0px/1px ».
 */
.c-form__choices .c-form__choice + .c-form__choice {
  border-block-start-width: 1px;
}

/*
 * Le pavé entier est le contrôle, et son intitulé est centré : c'est ce que
 * fait Heyflow, aucune puce n'y est dessinée. Le contrôle natif reste dans le
 * DOM — il n'est que réduit à un point par `form.css`, donc toujours
 * atteignable au clavier.
 */
.c-form__choice {
  justify-content: center;
  min-block-size: 56px;
  text-align: center;
}

.c-form__choice-mark {
  display: none;
}

.c-form__choice-text {
  flex: 0 1 auto;
}

.c-form__choice:has(.c-form__choice-input:checked) {
  background: var(--color-brand-500);
  border-color: var(--color-brand-500);
}

/* Une case de consentement seule garde sa puce : sans elle, rien ne dirait
   qu'elle est cochée. */
.c-form__field--checkbox:not(:has(.c-form__choices)) .c-form__choice-mark {
  display: block;
}

/*
 * Le bouton d'envoi : pilule claire alignée à droite, comme le « Continuer »
 * de Heyflow. `submitClass` vise par défaut les classes du blueprint, absentes
 * ici — sans ces règles, le bouton sort en barre pleine largeur.
 */
/*
 * `flex-direction` est redéclarée, et ce n'est pas une redondance.
 *
 * `form.css` pose `flex-direction: column` sur ce conteneur. Sans la remettre à
 * `row`, `justify-content: flex-end` s'applique à l'axe VERTICAL — elle ne fait
 * donc rien à l'horizontale — et c'est `align-items: center` qui décide, en
 * centrant le bouton. Mesuré le 30/09/2026 : conteneur 360→1080, bouton de
 * 159 px posé à 641, soit le centre exact, alors que le style calculé affichait
 * bien « flex-end ». Le rendu Heyflow, lui, aligne « Continuer » à droite.
 */
.c-form__actions {
  display: flex;
  flex-direction: row;
  justify-content: flex-end;
  align-items: center;
  gap: var(--space-s);
  flex-wrap: wrap;
  /*
   * L'air autour des boutons, relevé sur la production : la zone qui les porte
   * y est en `padding: 50px 0 20px`. Le natif n'en avait que les 16 px de
   * gouttière de la grille au-dessus, et rien en dessous — les boutons
   * collaient au dernier champ.
   *
   * Les 16 px de la grille se posent déjà entre le dernier champ et ce bloc :
   * on ne remet donc que le complément, et la soustraction est écrite plutôt
   * que calculée de tête, pour qu'elle suive le token si celui-ci change.
   */
  padding-block: calc(50px - var(--space-s)) 20px;
}

/*
 * Les deux boutons reprennent les valeurs relevées dans le shadow DOM de
 * Heyflow, où vit son habillage : « Continuer » en 14/20 de rentrée, bordure
 * transparente de 2 px, pilule ; « Retour » en fond blanc à 15 %, sans bordure,
 * posé à gauche.
 *
 * Le natif avait une rentrée de 12/40 — un bouton plus large et plus plat — et
 * un « Retour » à bordure sans fond. C'est le « boutons différents » de la
 * recette du 02/10/2026.
 */
.c-form__submit {
  justify-content: center;
  padding: 14px 20px;
  color: #1a1b23;
  background: var(--color-surface-sunken);
  border: 2px solid transparent;
  border-radius: var(--radius-full);
  font-family: inherit;
  font-size: 16px;
  /* 14 + 20 + 14 + 2×2 de bordure = les 52 px du bouton de production. */
  line-height: 20px;
  cursor: pointer;
  transition: background-color var(--motion-duration-fast) var(--motion-easing-standard);
}

/*
 * La flèche que porte le bouton de Heyflow. Le « / "" » lui donne un texte de
 * remplacement vide : elle se voit, elle ne s'annonce pas — un lecteur d'écran
 * dirait sinon « Continuer flèche vers la droite ».
 */
.c-form__submit::after {
  content: "→" / "";
  margin-inline-start: var(--space-2xs);
  transition: transform var(--motion-duration-fast) var(--motion-easing-standard);
}

.c-form__submit:hover {
  background: var(--color-brand-500);
}

.c-form__submit:hover::after {
  transform: translateX(3px);
}

@media (prefers-reduced-motion: reduce) {
  .c-form__submit::after {
    transition: none;
  }

  .c-form__submit:hover::after {
    transform: none;
  }
}

.c-form__prev {
  padding: 14px 16px;
  /*
   * Heyflow écrit ici `rgb(10, 9, 8)` — un texte quasi noir sur un blanc à 15 %
   * posé sur une page sombre, soit **1,9:1** de contraste. Mesuré le
   * 02/10/2026 en révélant le bouton, qui est masqué au premier écran. C'est
   * sous le seuil WCAG AA (4,5:1), et un bouton de retour illisible se
   * reproduit rarement exprès.
   *
   * La forme est donc reprise, la couleur non : blanc sur ce même fond donne
   * 7,4:1. C'est le seul écart assumé avec la production sur cette passe.
   */
  color: #fff;
  background: rgba(250, 250, 250, 0.15);
  /*
   * Transparente, donc invisible — elle n'est là que pour la hauteur. Heyflow
   * n'en met pas sur « Retour » alors que « Continuer » en porte 2 px, d'où
   * deux boutons de 44 et 48 px côte à côte. On garde l'aspect, on aligne.
   */
  border: 2px solid transparent;
  border-radius: var(--radius-full);
  font-family: inherit;
  font-size: 16px;
  /* La même hauteur que « Continuer » : 52 px. */
  line-height: 20px;
  cursor: pointer;
  transition: background-color var(--motion-duration-fast) var(--motion-easing-standard);
}

.c-form__prev:hover {
  background: rgba(250, 250, 250, 0.28);
}

/*
 * Dès qu'un « Retour » existe, il va à gauche et « Continuer » reste à droite :
 * c'est la classe `align-left` que porte le bouton de Heyflow.
 */
.c-form__actions:has(.c-form__prev) {
  justify-content: space-between;
}

/* Le message d'envoi et l'erreur restent lisibles sur la page sombre. */
.c-form__status,
.c-form__success {
  color: #fff;
}

.c-form__status.is-error {
  color: #ffb4ab;
}