/* * css/style.css — mise en page + identité visuelle du rapport. * Story 1.1/1.2 : structure/lisibilité minimale et navigation, en palette * neutre. Story 1.3 : la palette/typographie de marque est appliquée ici, * mais SEULEMENT via les custom properties de css/tokens.css (AD-3) — plus * aucune valeur hex/police codée en dur hors tokens.css. */ * { box-sizing: border-box; } body { margin: 0; font-family: var(--font-body-md-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-body-md-size); font-weight: var(--font-body-md-weight); line-height: var(--font-body-md-line-height); color: var(--color-on-surface); /* Neutre chaud, jamais de blanc pur pour un grand aplat de fond (cf. DESIGN.md Do's and Don'ts). */ background: var(--color-surface-container-low); /* Compense la hauteur de .site-nav (position:fixed, cf. plus bas) pour que le contenu ne démarre pas caché dessous. */ padding-top: var(--nav-height); /* Story 1.4 (FR11), correctif du point de vigilance Story 1.2 : un mot long non sécable (ex. "L'accompagnement", "certifications") dans un titre de section peut dépasser la largeur de sa boîte à 48px (--font-display-lg-size, jamais réduit ici — la typographie de la Story 1.3 n'est pas modifiée) et forcer le navigateur à élargir tout le viewport de mise en page plutôt que de scroller. `overflow-wrap` (hérité par tous les descendants) autorise la coupure d'un mot trop long uniquement quand c'est le seul moyen d'éviter ce débordement — confirmé nécessaire et suffisant en vérification navigateur à 360px (cf. Design Notes de cette story). */ overflow-wrap: break-word; /* Retour utilisateur (revue Sally, party mode) : `hyphens: auto` (correctif revue #5, story 1.4) insérait des traits d'union visibles dans ~60% des lignes de corps de texte sur mobile (ex. "ex-ploiter", "do-cumenter", "géné-rative") -- gênant en lecture courante, alors que la raison d'origine de cette règle (empêcher un mot long de titre, ex. "L'accompagnement"/"certifications", de faire déborder le viewport) est maintenant couverte séparément : h1-h4, `.site-nav__link` et `.chiffres-cles-liste` ont chacun leur propre `hyphens: none` explicite (ajoutés depuis), donc `body` ne pilote plus que le corps de texte courant, où la césure automatique n'a jamais été demandée. `manual` : les traits d'union insérés à la main dans le contenu source (rares) restent honorés, `auto` seul est retiré. `overflow-wrap: break-word` ci-dessus reste le filet de sécurité contre un débordement, inchangé -- seul le trait d'union automatique disparaît. */ hyphens: manual; } /* Correctif revue #3 (story 1.4) : défense en profondeur en plus d'overflow-wrap/hyphens ci-dessus — si un futur élément résiste malgré tout au retour à la ligne (ex. un tableau ou une image à largeur fixe, aucun des deux n'existe dans le contenu actuel), il reste caché plutôt que de provoquer un scroll horizontal ou d'élargir le viewport de mise en page. Sur les deux éléments racine car certains navigateurs appliquent le scroll sur html, d'autres sur body. */ html, body { overflow-x: hidden; } /* Retour utilisateur ("je ne vois pas trop la différence") : essai précédent -- "trame.png" (le picto du logo) répété 7 fois à des positions dispersées sur tout le fond de `body`, coordonnée verticale en PX FIGÉ (calculée une fois contre la hauteur totale de la page). Bug constaté en vérification navigateur (cause probable de "je ne vois pas la différence") : ces PX avaient été calculés contre la hauteur de page en LARGEUR MOBILE (~24 150px, le texte s'y enroule sur beaucoup plus de lignes) -- en largeur desktop (~1280px), la même page ne mesure plus que ~12 400px, quasiment la MOITIÉ. Résultat : les positions les plus basses (18 658px, 22 693px) tombaient hors de la page en desktop, et même les autres ne correspondaient plus au même endroit visuel -- 4 des 7 exemplaires ne s'affichaient jamais sur la largeur d'écran la plus consultée. Un simple recalcul des PX pour desktop aurait re-cassé au prochain ajout de contenu (même fragilité). Remplacé par UN exemplaire par GRANDE SECTION (`.section::before`, juste plus bas) plutôt que dispersé sur toute la page : chaque section a sa propre boîte, le filigrane s'y ancre en haut à droite avec un simple `top`/`right` FIXE EN PX DEPUIS LE COIN DE LA SECTION -- jamais une fraction de sa hauteur totale (qui varie énormément, ex. "Les études de branches" contient ~16 volets) donc jamais concerné par le bug ci-dessus ni par celui, plus ancien, de réaction à l'ouverture des volets (même famille de cause : une position en % ou calculée contre une hauteur qui bouge). Garanti visible sur CHAQUE section, à n'importe quelle largeur de viewport. Taille augmentée (420px, contre 220-380px avant) : plus présent, comme demandé -- toujours aucune opacité ajoutée, le filigrane reste pâle dans le fichier source lui-même. `position: relative`/`z-index: 0` : posés directement sur la règle `.section` établie plus bas dans ce fichier (padding/bordure/scroll- margin), pas ici en doublon -- cf. son propre commentaire pour le détail du contexte d'empilement que `z-index: 0` établit pour ce filigrane. */ .section::before { content: ""; position: absolute; /* Retour utilisateur (2e passe, "je ne vois pas trop la différence") : agrandi une 2e fois (420px -> 640px) et redescendu (6.5rem -> 11rem) -- à 420px/6.5rem, le filigrane tombait souvent sous des éléments déjà opaques en haut de section (le bloc "chiffres clés" d'avant-propos, notamment, le couvrait entièrement -- constaté en navigateur). Plus bas et plus grand : déborde largement de la zone d'intro dense de chaque section, plus de surface reste dégagée pour qu'il se voie malgré sa pâleur volontaire (toujours aucune opacité ajoutée). */ top: 11rem; right: 1.5rem; z-index: -1; width: 640px; height: 640px; background-image: url("../images/trame.png"); background-repeat: no-repeat; background-size: contain; pointer-events: none; } /* Retour utilisateur ("dans le footer je constate qu'une image d'arrière plan passe par dessus") : le filigrane ci-dessus (640px, ancré à top: 11rem) est pensé pour les GRANDES sections du rapport (cf. commentaire plus haut) -- la conclusion (`conclusion()`, _includes/section.njk), volontairement courte (2 paragraphes, aucun volet/chiffresCles), ne fait que ~590px de haut sur desktop. Le filigrane y déborde donc largement sous le bas de la section (176px + 640px de haut > sa propre hauteur), visible par-dessus le footer juste en dessous (constaté en navigateur) -- `.section` n'a pas `overflow: hidden` (le filigrane des AUTRES sections compte justement sur ce débordement pour rester visible même sous un bloc "chiffres clés" haut, cf. plus haut). Désactivé spécifiquement ici plutôt qu'un `overflow: hidden` global sur `.section` (casserait ce débordement voulu ailleurs) : la conclusion n'a de toute façon jamais eu besoin de ce filigrane, jamais demandé pour ce bloc de clôture. */ #conclusion::before { display: none; } /* Story 1.4 (FR11) : tout élément qui pourrait un jour dépasser la largeur de son conteneur (aucune image de contenu à ce stade, cf. Story 1.3 — seul le logo de nav, déjà borné par .site-nav__logo) reste contraint à la largeur disponible. Règle défensive, sans effet sur le logo (règle plus spécifique .site-nav__logo, cf. css/style.css plus bas). */ img { max-width: 100%; height: auto; } main { max-width: 1200px; margin: 0 auto; /* Story 1.4 (FR11) : remplace le padding fixe 1.5rem par les 3 paliers de marge de contenu de DESIGN.md (spacing.margin-mobile/-desktop, répliqués dans _data/theme.js et css/tokens.css, AD-3). Seule la marge horizontale (padding-inline) suit les paliers ; le padding vertical reste la valeur existante de la Story 1.1/1.2, hors scope de cette story. Mobile-first : <768px = spacing.margin-mobile (20px) par défaut ci-dessous, resserré/élargi par les media queries suivantes. */ padding-block: 1.5rem; /* Correctif revue #4 (story 1.4) : valeur de repli alignée sur la valeur actuelle de css/tokens.css (--spacing-margin-mobile: 20px), au cas où la custom property ne serait pas définie (ex. tokens.css absent/pas encore chargé). */ padding-inline: var(--spacing-margin-mobile, 20px); } /* Tablette (768–1023px) : marge resserrée intermédiaire entre mobile (20px) et desktop (80px). Aucun token dédié dans _data/theme.js pour ce palier (seuls margin-mobile/margin-desktop y sont définis, cf. Code Map de cette story) — valeur choisie directement ici plutôt que d'inventer un nouveau token/décision d'architecture non demandée. Même valeur appliquée à .site-nav__inner (cf. plus bas) pour garder les bords de la nav alignés avec ceux du contenu à ce palier (correctif revue #1). */ @media (min-width: 768px) { main { padding-inline: 2.5rem; } } /* Desktop (≥1024px) : marge de contenu généreuse, spacing.margin-desktop (80px, DESIGN.md/_data/theme.js/css/tokens.css). */ @media (min-width: 1024px) { main { /* Correctif revue #4 : repli aligné sur css/tokens.css (--spacing-margin-desktop: 80px). */ padding-inline: var(--spacing-margin-desktop, 80px); } } /* --------------------------------------------------------------------- * Hero (spec largeur-1200px-bandeau-hero) : bloc en flux normal juste * après la nav fixe, PAS fixe lui-même -- défile normalement au scroll. * `background-color` posé ici (sur .hero, pas .hero__inner) : repli si * `heroFond` est absent (défaut, aucun fond photo fourni à ce stade) ET * repli si l'image fournie ne charge pas -- cf. `.hero--fond` juste plus * bas pour le fond photo lui-même (distinct de la vignette encadrée * `.hero__photo-frame`, plus bas dans ce fichier, pilotée par `heroImage`). * * Retour utilisateur (2e passe) : `--color-primary` (identique à * `.site-nav`, plus bas dans ce fichier) faisait fondre le hero dans la * nav fixe juste au-dessus -- aucune limite visible entre les deux bandes * au chargement de la page. Éclairci en `--color-primary-fixed-dim` * (tokens.css, #297CA3 -- variante "fixed" de la famille M3 du bleu de * marque, pensée précisément pour porter du texte blanc sur un fond plus * clair que `--color-primary`) plutôt qu'une valeur hex inventée ici * (AD-2) : contraste blanc/fond vérifié à 4,67:1, largement au-dessus des * 3:1 (grand texte, le titre) et 4,5:1 (texte courant, WCAG AA) requis -- * `--color-on-primary` reste donc utilisable tel quel sur ce nouveau fond, * aucun changement de couleur de texte nécessaire. * --------------------------------------------------------------------- */ .hero { background-color: var(--color-primary-fixed-dim); min-height: var(--hero-band-min-height); display: flex; /* Retour utilisateur (3e passe) : `align-items: center` (ancienne valeur) ne centrait qu'un `.hero__inner` de hauteur "naturelle" (celle du texte, ~200px) dans la bande -- le repli photo, à l'intérieur, ne pouvait donc jamais dépasser cette même hauteur réduite, laissant un vide au-dessus/en dessous de lui alors que la bande elle-même est bien plus haute (`--hero-band-min-height`). `stretch` étire `.hero__inner` sur TOUTE la hauteur de la bande -- son repli photo (`align-items: stretch`, comportement flex par défaut, cf. `.hero__inner .image-placeholder` plus bas) en hérite directement. Le texte, qui n'a plus ce centrage automatique, se recentre lui-même à l'intérieur de sa propre boîte désormais étirée (cf. `.hero__text` plus bas). */ align-items: stretch; /* Correctif : ancre de positionnement du numéral fantôme -- doit être .hero (toute la hauteur de la bande) et non .hero__inner (hauteur du seul bloc de texte), sinon le numéral colle au sous-titre au lieu de s'étendre en filigrane sur toute la bande (visible surtout sur mobile, où .hero__inner est plus bas que .hero). */ position: relative; /* Retour utilisateur (halos, vérification navigateur) : `z-index: 0` explicite -- `.hero` n'établissait jusqu'ici AUCUN contexte d'empilement propre (position:relative seul, sans z-index, n'en crée pas). `.hero__halos` (position:absolute, cf. plus bas) et `.hero__text` (position:relative, cf. plus bas) sont TOUS DEUX des descendants positionnés SANS lien de parenté directe entre eux -- sans un contexte d'empilement commun explicite ici, leur ordre de peinture relatif suit des règles d'empilement CSS qui, en pratique (vérifié en navigateur), plaçaient `.hero__text` AU-DESSUS de `.hero__halos` même quand celui-ci est plus tôt dans le DOM -- le halo se retrouvait cachÉ derrière le bloc de texte (transparent en dehors des glyphes, mais le texte lui-même bloquait le halo pile où il aurait dû le border). Ce `z-index: 0` fait de `.hero` LA référence d'empilement pour tous ses descendants positionnés -- permet à `.hero__halos` de prendre un z-index NÉGATIF (plus bas, scopé ICI, jamais en dehors de `.hero`) pour repasser proprement sous tout le reste (texte, numéral, photo) sans dépendre de subtilités d'ordre du DOM. */ z-index: 0; /* Clippe le numéral fantôme (position absolute, très grand) pour qu'il ne déborde jamais sur les petits viewports. */ overflow: hidden; } /* Retour utilisateur : fond photo de toute la bande (`heroFond`, _data/rapport.js/layout.njk) avec un voile bleu par-dessus -- distinct de la vignette encadrée `.hero__photo-frame` (plus bas), qui affiche une 2e image séparée (`heroImage`) à côté du texte. Voile en couche UNIQUE (même teinte aux deux extrémités du gradient, pas un dégradé haut/bas comme un 1er essai précédent, retiré). Intensité ajustée par petites touches successives à la demande de l'utilisateur : 30% ("léger", à l'origine) -> 37,5% (+25% relatifs) -> 50% -> 70% (valeurs exactes demandées directement). `background-image` n'est PAS posée ici (retour utilisateur, bug sous-dossier) : layout.njk pose désormais le dégradé ET la photo directement en style inline sur `
` (formule dupliquée depuis ici, cf. son commentaire) -- une custom property `--hero-fond` consommée par une règle ici résolvait les URL relatives contre CE fichier CSS plutôt que contre la page. `color-mix` de `--color-primary- fixed-dim` (AD-2) reste la seule source de vérité pour la couleur. */ .hero--fond { background-size: cover; background-position: center; } /* --------------------------------------------------------------------- * Halos de couleur du hero (retour utilisateur, "donner de la vie" puis * "beaucoup plus gros... mouvement aléatoire perpétuel") -- cf. * commentaire de `.hero__halos` dans layout.njk pour le contexte. Dérive * perpétuelle demandée explicitement par l'utilisateur : EXCEPTION * consciente à l'interdit "jamais de boucle" d'EXPERIENCE.md > Interaction * Primitives > "Banni" (contre-métrique PRD SM-C1, effet gadget) -- * décision documentée, pas un oubli. Scopée à ce seul fond purement * décoratif (`aria-hidden`, cf. `@keyframes hero-halo-drift-1/2/3` plus * bas pour le détail des trajectoires). * --------------------------------------------------------------------- */ .hero__halos { position: absolute; inset: 0; overflow: hidden; pointer-events: none; /* Correctif (vérification navigateur) : `z-index: -1`, scopé au contexte d'empilement de `.hero` (`z-index: 0` explicite, cf. plus haut) -- repasse le halo sous TOUT le reste du hero (texte, numéral fantôme, photo du personnage), quel que soit l'ordre du DOM entre eux. Ancien raisonnement ("aucun z-index nécessaire, l'ordre du DOM suffit") dépassé -- `.hero__text` (position:relative) passait quand même par-dessus en pratique (bug constaté : le halo disparaissait entièrement derrière le bloc de texte). */ z-index: -1; /* Retour utilisateur ("prendre l'intégralité du header, un océan qui existe même en dehors de ses frontières") : dégradé de fond STATIQUE -- toujours présent, sur TOUTE la surface de `.hero__halos` (donc de `.hero`), indépendamment de la position des 3 halos mobiles ci-dessous. C'est LUI qui garantit qu'il n'y a jamais de vide, plutôt que de compter sur des halos assez gros et assez rapprochés pour se recouvrir en permanence -- ce qui les faisait justement "fusionner" (retour utilisateur : "cela les rend opaques", cf. commentaire de layout.njk). Les halos, ci-dessous, deviennent des touches de couleur un peu plus présentes QUI SE DÉPLACENT par-dessus cet océan déjà là, jamais la seule source de couverture. Radiaux très étendus (150% de large/haut) centrés hors-cadre (coins) : le dégradé déborde largement des bords de `.hero__halos` -- l'"océan" continue visuellement au-delà du cadre visible, seule sa fenêtre change. Même trio de teintes "container" que les halos, à très faible opacité. */ background: radial-gradient(150% 150% at 10% 15%, color-mix(in srgb, var(--color-primary-container) 22%, transparent), transparent 65%), radial-gradient(150% 150% at 92% 85%, color-mix(in srgb, var(--color-secondary-container) 18%, transparent), transparent 65%), radial-gradient(140% 140% at 85% 8%, color-mix(in srgb, var(--color-tertiary-container) 15%, transparent), transparent 60%); } .hero__halo { position: absolute; /* Retour utilisateur (référence technique "liquid halo" partagée) : forme organique (4 rayons différents par axe) plutôt qu'un cercle parfait (`border-radius: 50%`, essai précédent) -- technique CSS pure couramment utilisée pour des "blobs" liquides, sans avoir besoin de tracés SVG. Un cercle parfait n'a AUCUN rendu différent selon son angle de rotation (par définition) -- cette forme asymétrique est ce qui permet à la légère rotation ajoutée aux trajectoires plus bas de produire un effet réellement visible ("liquide"), pas un no-op. */ border-radius: 42% 58% 61% 39% / 45% 48% 52% 55%; /* Flou important (retour utilisateur, "flou gaussien maximum pour diluer") : dilue la couleur en une touche douce plutôt qu'un disque nettement contouré. */ filter: blur(60px); /* Retour utilisateur ("le mode screen ne doit pas fonctionner car j'ai juste du blanc... overlay, mode incrustation ?") : `overlay` -- `screen` avec un halo BLANC PUR n'a mathématiquement qu'un seul résultat possible (blanc plein, quel que soit le fond en dessous : `1 - (1-1)×(1-fond) = 1`) -- ça ne "s'accorde" jamais avec la photo, ça la recouvre platement, d'où le "j'ai juste du blanc" constaté. `overlay` combine Multiply/Screen SELON la luminosité du fond : il éclaircit les zones déjà claires ET assombrit légèrement les zones déjà sombres -- la texture/le contraste de la photo restent visibles À TRAVERS le halo blanc plutôt que d'être effacés, exactement le "on voit l'image de fond" demandé depuis plusieurs passes. */ mix-blend-mode: overlay; } /* Trio dérivé du bleu de marque (section "globale", cf. DESIGN.md > Colors > "dégradés... toujours dérivés de la couleur de section dominante") -- les 3 teintes "container" de _data/theme.js (déjà validées, AD-1/AD-2), jamais une couleur inventée. Essai intermédiaire en blanc uni (retour utilisateur, "ça fera juste des zones plus claires... peut-être mieux ?") comparé en navigateur puis ABANDONNÉ au profit de ce trio -- retour utilisateur explicite ("remets les couleurs précédentes"). `mix-blend- mode: overlay` (plus haut) fonctionne avec ces 3 couleurs comme avec le blanc : il éclaircit/assombrit selon la luminosité du fond, la couleur du halo reste visible en teinte plutôt que lavée en simple luminosité. Ne peuvent structurellement jamais couvrir le personnage, cf. commentaire de `.hero__halos` dans layout.njk (z-index négatif, toujours sous `.hero__photo-frame`). Retour utilisateur ("ils doivent se repousser comme des aimants ou de l'huile dans l'eau" -- jamais fusionner, jamais se chevaucher au point d'opacifier) : chaque halo occupe un TERRITOIRE propre -- halo 1 à gauche, halo 2 en bas à droite, halo 3 en haut à droite -- avec une orbite assez resserrée (cf. `@keyframes hero-halo-drift-*` plus bas) pour ne JAMAIS empiéter sur le territoire des 2 autres. C'est cette séparation qui donne l'effet "répulsion", pas une fusion de leurs bords. Tailles réduites par rapport à une passe précédente (elles n'ont plus besoin, seules, de couvrir toute la bande -- l'océan de fond ci-dessus s'en charge) -- toujours largement plus grandes que leur territoire pour y "flotter" sans jamais laisser voir un bord net. `--hero-halo-opacity` : source UNIQUE de l'opacité cible de chaque halo (repos ET dérive, cf. `@keyframes` plus bas qui ne touchent que `transform`). */ .hero__halo--1 { top: 15%; left: -15%; width: 60vw; height: 60vw; max-width: 680px; max-height: 680px; background: var(--color-primary-container); --hero-halo-opacity: 0.65; opacity: var(--hero-halo-opacity); } .hero__halo--2 { bottom: -25%; right: -15%; width: 50vw; height: 50vw; max-width: 560px; max-height: 560px; background: var(--color-secondary-container); --hero-halo-opacity: 0.55; opacity: var(--hero-halo-opacity); /* Forme propre, distincte de `.hero__halo` (règle commune) -- 3 blobs identiques auraient l'air d'un seul motif dupliqué 3 fois. */ border-radius: 55% 45% 38% 62% / 62% 40% 60% 38%; } .hero__halo--3 { top: -20%; right: -10%; width: 42vw; height: 42vw; max-width: 480px; max-height: 480px; background: var(--color-tertiary-container); --hero-halo-opacity: 0.48; opacity: var(--hero-halo-opacity); border-radius: 63% 37% 51% 49% / 39% 58% 42% 61%; } /* Retour utilisateur ("les trois halos doivent être animés tout le temps, traverser, se repousser" -> "mouvement plus lent" -> "ils doivent se repousser comme des aimants ou de l'huile dans l'eau") : dérive continue -- SEULE exception du site à "jamais de boucle" (EXPERIENCE.md > Interaction Primitives > "Banni"), demandée explicitement et à plusieurs reprises par l'utilisateur pour ce fond purement décoratif (aucun contenu, aucune fonction, `aria-hidden`). 3 orbites LOCALES et DISTINCTES, une par territoire (cf. commentaire de `.hero__halo--1` plus haut) : chaque halo tourne/dérive autour de SA PROPRE position de repos sans jamais s'approcher des 2 autres -- contrairement aux passes précédentes (trajectoires longues qui traversaient toute la bande, ou halos si gros que leur chevauchement permanent les fusionnait), l'amplitude reste volontairement modeste pour ne jamais quitter le territoire assigné. `rotate()` ajouté (retour utilisateur, référence technique "liquid halo") : sans forme asymétrique, une rotation n'aurait aucun effet visible sur un cercle -- c'est justement pour ça que `.hero__halo` est passé à un `border-radius` à 8 valeurs (organique, cf. son commentaire) juste avant. `prefers-reduced-motion: reduce` neutralise entièrement cette exception : halos parfaitement statiques (repli `opacity`/position de base ci-dessus), comme tout le reste du site. */ /* Retour utilisateur ("augmente la vitesse x2") : durées divisées par 2 (34/42/38s -> 17/21/19s), délais divisés par 2 à l'identique pour garder le même DÉCALAGE RELATIF entre halos (donc les mêmes croisements de trajectoires, juste deux fois plus vite). */ @media (prefers-reduced-motion: no-preference) { .hero__halo--1 { animation: hero-halo-drift-1 17s ease-in-out infinite; } .hero__halo--2 { animation: hero-halo-drift-2 21s ease-in-out infinite; animation-delay: -7s; } .hero__halo--3 { animation: hero-halo-drift-3 19s ease-in-out infinite; animation-delay: -4s; } @keyframes hero-halo-drift-1 { 0% { transform: translate(0, 0) rotate(0deg) scale(1); } 25% { transform: translate(20%, -22%) rotate(35deg) scale(1.2); } 50% { transform: translate(-14%, 14%) rotate(-20deg) scale(0.85); } 75% { transform: translate(12%, 22%) rotate(15deg) scale(1.1); } 100% { transform: translate(0, 0) rotate(360deg) scale(1); } } @keyframes hero-halo-drift-2 { 0% { transform: translate(0, 0) rotate(0deg) scale(1); } 30% { transform: translate(-20%, -16%) rotate(-30deg) scale(0.88); } 60% { transform: translate(16%, 18%) rotate(20deg) scale(1.2); } 85% { transform: translate(-10%, 12%) rotate(-10deg) scale(0.92); } 100% { transform: translate(0, 0) rotate(-360deg) scale(1); } } @keyframes hero-halo-drift-3 { 0% { transform: translate(0, 0) rotate(0deg) scale(1); } 35% { transform: translate(-16%, 18%) rotate(25deg) scale(1.15); } 65% { transform: translate(14%, -14%) rotate(-25deg) scale(0.85); } 100% { transform: translate(0, 0) rotate(360deg) scale(1); } } } .hero__inner { /* Mêmes paliers de marge horizontale que `main`/.site-nav__inner ci-dessus, pour que le contenu du hero reste aligné avec le reste de la page à chaque palier. Pas de `position: relative` ici (correctif) : le numéral fantôme doit s'ancrer à `.hero` (toute la bande), pas à ce bloc -- le laisser positionné en ferait la référence la plus proche pour `.hero__numeral`, ce qu'on veut justement éviter. */ width: 100%; max-width: 1200px; margin: 0 auto; padding-block: 3rem; padding-inline: var(--spacing-margin-mobile, 20px); /* Retour utilisateur (7e passe -- coller au bas, tablette) : `.hero` s'étire à `min-height: 60vh` (plus haut) même quand le texte + la photo empilés n'en ont pas besoin -- sur tablette (768-1023px, sous le palier desktop qui passe en rangée plus bas), l'ancien flux bloc laissait tout cet excédent s'accumuler APRÈS le dernier enfant (le cadre photo), pas collé au bas comme demandé (bug constaté en vérification indépendante : 164px de vide sous le cadre à 768×1024, bien plus que les 48px de padding attendus). `display: flex; flex- direction: column` transforme texte + cadre en enfants flex empilés -- `margin-top: auto` sur le cadre (plus bas) absorbe alors tout l'excédent au-dessus de lui plutôt qu'en dessous, le collant au bas quelle que soit la hauteur réelle de la bande. Repassé en `flex-direction: row` à partir de 1024px (media query plus bas). */ display: flex; flex-direction: column; } @media (min-width: 768px) { .hero__inner { padding-inline: 2.5rem; } } @media (min-width: 1024px) { .hero__inner { padding-inline: var(--spacing-margin-desktop, 80px); /* Repasse en rangée : la base (plus haut) empile texte + photo en colonne pour le palier mobile/tablette (`margin-top: auto` sur le cadre photo, plus bas) -- inutile/sans effet ici, la rangée + le `flex: 0 0 ...` du cadre gèrent déjà côte-à-côte et pleine hauteur. */ flex-direction: row; } } /* Retour utilisateur : zone photo à côté du texte du hero (`imagePlaceholder()`, layout.njk -- même repli "photo à venir" que les autres sections tant qu'aucune image n'est fournie). Empilé par défaut (mobile/tablette, ordre DOM texte puis image = déjà correct sans règle supplémentaire) ; côte à côte à partir de 1024px, palier "desktop" du projet, largeur fixe partagée avec les autres repli photo du site (`--secondary- column-width`, tokens.css). `align-items: stretch` (comportement flex par défaut, non repris ici) : `.hero__inner` étant lui-même étiré sur toute la hauteur de `.hero` (cf. `align-items: stretch` sur `.hero` plus haut), le repli photo en hérite directement -- il occupe maintenant toute la hauteur RÉELLE de la bande, pas seulement celle du texte voisin. */ @media (min-width: 1024px) { .hero__inner { display: flex; gap: calc(var(--spacing-gutter) * 2); } /* `display: flex; flex-direction: column; justify-content: center` : `.hero__text` est lui-même étiré (comportement stretch hérité de `.hero__inner`) sur toute la hauteur de la bande -- sans ce recentrage, le kicker+titre se retrouveraient collés en haut de cette boîte désormais haute plutôt que verticalement centrés comme avant (quand `.hero` centrait directement `.hero__inner`, cf. plus haut). */ .hero__text { flex: 1; display: flex; flex-direction: column; justify-content: center; } /* Retour utilisateur (4e passe) : `align-items: stretch` (plus haut) étire le repli photo/le cadre de la photo réelle sur la hauteur de `.hero__inner`, mais celle-ci reste réduite du `padding-block: 3rem` du conteneur (plus haut) -- le texte en a besoin pour respirer, l'image non. `margin-block: -3rem` (l'exact opposé, littéral pour rester lisible plutôt qu'une variable pour une valeur utilisée à cet unique endroit) fait déborder l'image de cette même distance en haut ET en bas, l'amenant à toucher les bords réels de `.hero` -- vérifié en direct : hauteur désormais identique à celle de la bande, à l'arrondi près. Règle commune au repli `.image-placeholder` ET au cadre de la vraie photo (`.hero__photo-frame`, cf. plus bas) : même boîte, même comportement, que l'image soit fournie ou non. Retour utilisateur (5e passe) : `.hero__photo` (l'`` lui-même) était initialement l'enfant flex directement dimensionné ici -- `` est un élément remplacé avec un ratio intrinsèque propre (1122×1402) : une fois étiré (`align-items: stretch`), le navigateur recalculait sa largeur à partir de CE ratio plutôt que de respecter `flex-basis: 420px` (bug constaté en vérification indépendante : 1040×1300px rendus, exactement le ratio source à l'échelle -- `flex- basis` mesurait pourtant bien 420px dans les styles calculés, mais sans effet sur le rendu final). `.hero__photo-frame` (div neutre, cf. layout.njk) est maintenant le SEUL enfant flex dimensionné ici -- un simple `
` n'a aucun ratio intrinsèque à faire valoir, il obéit normalement à `flex-basis`/stretch. `.hero__photo` (plus bas) se contente de remplir ce cadre déjà correctement dimensionné. */ .hero__inner .image-placeholder, .hero__inner .hero__photo-frame { flex: 0 0 var(--secondary-column-width); margin-block: -3rem; } /* Retour utilisateur (6e/8e passes -- tablette/mobile) : en dessous de ce palier, `.hero__photo-frame` est contraint par `aspect-ratio`/ `max-height` (cf. règle plus bas) pour plafonner l'`` à ratio intrinsèque qu'elle contient -- les trois neutralisées ici (`height`/`aspect-ratio`/`max-height` tous `auto`/`none`) pour laisser `align-items: stretch` reprendre ENTIÈREMENT la main sur desktop, exactement comme `.hero__photo` avait déjà eu besoin du même correctif en 4e passe (plus haut). */ .hero__inner .hero__photo-frame { height: auto; aspect-ratio: auto; max-height: none; } } /* Retour utilisateur (7e passe -- coller au bas, tablette/mobile) : `margin-top: auto` sur l'image/le repli, dans la colonne flex posée par `.hero__inner` (base, plus haut) pour ce palier -- absorbe tout l'excédent de hauteur entre le texte et le bas de la bande (`.hero` s'étire à `min-height: 60vh`, souvent plus haut que le contenu réel) au-dessus de l'image plutôt qu'en dessous, la collant au bord bas de `.hero`. Portée à `max-width: 1023px` explicitement (plutôt qu'une règle non bornée + un correctif `margin-top` dans le palier desktop) pour éviter toute ambiguïté de cascade avec `margin-block: -3rem` du palier desktop (plus haut) sur la même propriété. `.hero__inner .image- placeholder` (pas `.image-placeholder` seul, classe générique utilisée par d'autres sections du site) : la portée reste strictement le hero. */ @media (max-width: 1023px) { .hero__inner .image-placeholder, .hero__photo-frame { margin-top: auto; } } /* Cadre neutre de la photo réelle du hero (`heroImage.src`, layout.njk) -- remplace le repli `.image-placeholder` dans la MÊME boîte plutôt que de peindre un fond pleine largeur derrière tout le hero (mécanisme `.hero--photo` retiré). `overflow: hidden` : nécessaire pour que `border-radius` rogne aussi l'`` à l'intérieur (un `border-radius` posé sur l'image seule serait masqué par ses propres bords nets sans ce clip côté parent). Retour utilisateur (6e passe -- tablette/mobile) : `min-height: 200px` (essai précédent, calqué sur `.image-placeholder`) ne plafonnait RIEN pour un `` réel -- `.image-placeholder` est un simple `
` sans contenu propre, `min-height` EST alors sa hauteur ; `.hero__photo` (l'``, cf. plus bas) a un ratio intrinsèque (1122×1402) qui pousse ce cadre bien AU-DELÀ du plancher dès que rien ne l'en empêche -- bug constaté en vérification indépendante : bande hero mesurée à 1079px de haut sur tablette (768×1024, l'écran ENTIER ne fait que 1024px), 699px sur mobile. Retour utilisateur (8e passe -- "tête qui vole") : une hauteur FIXE (`height: 260px`, essai précédent) plafonnait bien la hauteur, mais la LARGEUR du cadre grandit avec le viewport sur toute la plage empilée (375-1023px, cf. `flex-direction: column` sur `.hero__inner`, plus haut) -- vers ~900px de large, le cadre devenait très large et très plat (805×260 mesuré, ratio ~3:1) alors que la photo est un portrait (1122×1402, ratio ~0,8:1) : `object-fit: cover` doit alors zoomer ÉNORMÉMENT pour couvrir cette largeur, ne laissant plus voir qu'une fine tranche du haut de la photo -- "juste une tête qui vole" (retour utilisateur), la largeur du cadre remplie presque entièrement de fond autour d'une tête minuscule. `aspect-ratio: 4 / 3` (au lieu d'une hauteur fixe) fait grandir la hauteur EN PROPORTION de la largeur -- le cadre reste un rectangle raisonnable à toute largeur intermédiaire, jamais démesurément plat. `max-height: 420px` : plafond de sécurité pour ne pas non plus grandir sans limite juste avant le palier desktop (1023px de large -> ~682px de haut sans lui). Neutralisés (`aspect- ratio: auto`, `max-height: none`) à partir de 1024px (media query plus haut) pour laisser `align-items: stretch` reprendre entièrement la main sur desktop. Retour utilisateur (7e passe -- coller au bas) : `margin-bottom: -3rem` fait déborder le cadre du padding-bottom de `.hero__inner` (3rem, cf. plus haut) pour toucher le bord réel du bas de `.hero` -- même technique que le débord `margin-block: -3rem` du palier desktop (plus haut dans ce fichier), mais SEULEMENT en bas ici : contrairement au desktop (où la photo occupe toute la hauteur de la bande), le texte précède la photo dans l'empilement mobile/tablette et a besoin de son propre espacement au-dessus -- seul le bas, qui ne touche plus aucun autre contenu avant la fin de la bande, doit déborder. */ .hero__photo-frame { aspect-ratio: 4 / 3; max-height: 420px; margin-bottom: -3rem; border-radius: var(--rounded); overflow: hidden; } /* `object-fit: cover` : l'image fournie (portrait, 1122×1402) remplit ce cadre plus large que haut sans se déformer, quitte à en rogner les bords -- même logique que `background-size: cover` utilisé partout ailleurs sur le site pour une image de remplissage. `width`/`height` 100% : remplit le cadre déjà dimensionné par `.hero__photo-frame` ci-dessus, sans jamais imposer son propre ratio intrinsèque (cf. commentaire de la 5e passe plus haut -- exactement le problème que ce cadre neutre permet d'éviter). */ /* Retour utilisateur : `object-position: top` -- quand le cadre plus court que l'image (portrait, 1122×1402) force `object-fit: cover` à rogner, le haut de la photo (visage) doit toujours rester visible, jamais le centre (défaut du navigateur, `50% 50%`, qui rognait autant en haut qu'en bas). Le rognage porte donc entièrement sur le bas de l'image. */ .hero__photo { display: block; width: 100%; height: 100%; object-fit: cover; object-position: top; } /* Numéral fantôme "2025" -- simple effet typographique (texte, pas une image), inspiré du grand "2024" en transparence du site 2024. Opacité réduite pour ne jamais entraver la lecture du titre/accroche au-dessus (position:relative sur .hero__title/.hero__subtitle, cf. plus bas). */ .hero__numeral { position: absolute; /* Correctif revue : ancré à `.hero` (toute la bande) plutôt qu'à `.hero__inner`, `left: 0` collerait le numéral au bord réel du viewport sur les très grands écrans (≥1360px), où `.hero__inner` (max-width 1200px + 80px de marge desktop) se retrouve centré avec un espace vide de chaque côté -- le numéral se déconnecterait alors visuellement du titre/accroche. Ce calcul reproduit le bord gauche réel du contenu de `.hero__inner` (centrage 1200px + inset 80px). */ left: max(0px, calc(50% - 600px + var(--spacing-margin-desktop, 80px))); /* Retour utilisateur ("le 2025 du header se cache") : remonté de `--avant-propos-overlap` (tokens.css, même token que la marge négative de `#avant-propos .section-band` plus bas dans ce fichier) -- sans ce décalage, le tiers inférieur des glyphes se retrouvait sous la bande "Avant-propos" qui chevauche désormais le bas du hero, rendant "25" illisible (bug constaté en vérification navigateur, largeur réduite). `calc()` plutôt qu'une valeur fixe : reste correct si la police/la hauteur de bande changent un jour, un seul token à ajuster (AD-2). */ bottom: calc(-0.1em + var(--avant-propos-overlap)); font-family: var(--font-display-lg-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: clamp(6rem, 20vw, 16rem); font-weight: var(--font-display-lg-weight); line-height: 1; color: var(--color-on-primary); opacity: 0.18; pointer-events: none; user-select: none; } /* Retour utilisateur (2e passe -- hiérarchie inversée) : enveloppe le kicker + le titre (cf. layout.njk) pour porter `position: relative` (nécessaire pour que les deux passent AU-DESSUS du numéral fantôme, positionné en absolute sur `.hero`, cf. `.hero__numeral` plus haut -- auparavant chacun des deux le portait individuellement) et servir de colonne "texte" dans la mise en page à 2 colonnes de `.hero__inner` (repli photo à côté, cf. plus haut) sans affecter la largeur du numéral, resté ancré à `.hero` en dehors de cette colonne. */ .hero__text { position: relative; } /* Kicker : petit repère ("Rapport d'activité 2025", un simple repère d'année, pas le titre éditorial de ce rapport) au-dessus du VRAI titre -- traité en majuscules + espacement des lettres pour se lire comme une étiquette de catégorie plutôt qu'un second titre, à la manière d'une Une de magazine. Taille reprise de l'ancien `.hero__subtitle` (corps de texte large, --font-body-lg) : suffisamment lisible sans jamais rivaliser avec `.hero__title` juste en dessous. */ .hero__kicker { margin: 0 0 0.5rem; font-family: var(--font-body-lg-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-body-lg-size); font-weight: 600; line-height: var(--font-body-lg-line-height); letter-spacing: 0.06em; text-transform: uppercase; color: var(--color-on-primary); } .hero__title { margin: 0; font-family: var(--font-display-lg-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-display-lg-size); font-weight: var(--font-display-lg-weight); line-height: var(--font-display-lg-line-height); letter-spacing: var(--font-display-lg-letter-spacing); color: var(--color-on-primary); } /* Mobile (FR11, même principe que h2 plus bas) : le palier mobile du titre affiché dans le hero, et un plancher de hauteur réduit par rapport aux 60vh desktop -- sur un petit écran, 60vh laisse un bloc disproportionné par rapport au contenu (titre + accroche courts), cf. Design Notes/I-O matrix de la spec ("minHeight peut être réduit à un palier mobile"). */ @media (max-width: 767px) { .hero { min-height: min(var(--hero-band-min-height), 24rem); } .hero__title { font-size: var(--font-display-lg-mobile-size); line-height: var(--font-display-lg-mobile-line-height); letter-spacing: var(--font-display-lg-mobile-letter-spacing); } } /* Retour utilisateur (revue Sally, party mode) : `--spacing-section-gap` (96px, tokens.css) était défini par DESIGN.md > Layout & Spacing -- "un espace généreux qui signale un vrai changement de sujet, cohérent avec la structure en chapitres du rapport" -- mais jamais consommé nulle part (vérifié par grep) : les sections n'étaient séparées que par 2.5rem (40px) + un filet 1px, cinq chapitres se lisant comme un flux continu plutôt que des chapitres distincts. */ .section { padding-block: 0 var(--spacing-section-gap); border-bottom: 1px solid var(--color-outline-variant); /* Décale la cible de scroll (ancre de nav/deep-link) sous .site-nav (position:fixed), même mécanisme que .volet__toggle plus bas. */ scroll-margin-top: var(--nav-height); /* Retour utilisateur ("filigrane sur les grandes sections") : contexte d'empilement propre -- permet à `.section::before` (le filigrane `trame.png`, cf. son commentaire tout en haut de ce fichier) de repasser sous TOUT le contenu réel de la section via un z-index négatif SCOPÉ ICI, même technique déjà éprouvée sur `.hero` plus haut (bug analogue rencontré et corrigé là-bas : un enfant positionné sans z-index explicite peut sinon passer au-dessus d'un texte pourtant plus tôt dans le DOM). */ position: relative; z-index: 0; } .section:last-child { border-bottom: none; } /* Retour utilisateur (revue Sally, party mode) : les paragraphes de prose narrative mesuraient jusqu'à 140-142 caractères par ligne à 1440px (intro "portail", intro "travaux interbranches") -- très au-delà de la plage lisible (~60-75 car., déjà noté non tranché dans deferred-work.md faute de valeur précise). La valeur manquante était déjà dans le site : le corps d'un volet ouvert lit à 62 caractères (contraint par la largeur de sa carte). `68ch` reprend ce même ordre de grandeur pour toute la prose. Volontairement large (`.section p`, pas un sélecteur plus restrictif) pour couvrir tous les contextes où `renderCorps()`/ `renderBloc()` produit des `

` -- corps de section empilé, colonnes (avant-propos), encadré, rubrique, textes du portail, veille prospective -- sans exception à maintenir à la main. Les grilles de volets ne sont PAS concernées en pratique : leur carte est déjà plus étroite que 68ch, la règle ne peut donc jamais y élargir quoi que ce soit, seulement rétrécir là où c'est encore trop large. */ .section p { max-width: 68ch; } /* Retour utilisateur (2e passe) : le texte d'intro d'une section sans colonne voisine (`.section-intro`, _includes/section.njk -- portail, travaux-interbranches, etudes-de-branches, certifications) restait aligné à gauche une fois plafonné à 68ch ci-dessus -- le vide à droite sur grand écran se lisait comme un oubli plutôt qu'une marge voulue. Un 1er essai l'a centré (`margin-inline: auto`) : jugé "bizarre et perturbant" -- ça cassait l'alignement à gauche partagé avec le titre de section et le reste de la page. Remplacé par une vraie 2e colonne (`.section-intro-row` ci-dessous) : le texte reste aligné à gauche, `max-width` seule suffit maintenant (la colonne elle-même est déjà plus étroite que 68ch une fois la grille posée -- répétée malgré tout pour le cas où `.section-intro-row` n'existe pas encore dans le DOM). */ .section-intro { max-width: 68ch; } .section-intro > :first-child { margin-top: 0; } /* Retour utilisateur ("met le texte sur 2 colonnes équilibré") : les 2 paragraphes du bloc de conclusion (`conclusion()`, _includes/section.njk) -- une grille à 2 colonnes STRICTEMENT égales (1fr 1fr, contrairement à `.section-columns` plus bas dont le ratio 600px/320px est volontairement inégal texte+chiffresCles) plutôt qu'un flux `column-count: 2` : chaque paragraphe reste entier dans SA colonne, jamais coupé au milieu entre les deux. Empilé par défaut (mobile/tablette) -- même palier "desktop" que `.section-columns`/`.section-intro-row` pour rester cohérent avec le reste du site. */ @media (min-width: 1024px) { .conclusion-columns { display: grid; grid-template-columns: 1fr 1fr; gap: calc(var(--spacing-gutter) * 2); } .conclusion-columns > :first-child { margin-top: 0; } } /* Retour utilisateur : 2e colonne à côté du texte d'intro, occupée par un repli "photo à venir" (`imagePlaceholder()`, _includes/section.njk) plutôt que laissée vide -- largeur FIXE (`--secondary-column-width`, css/tokens.css), pas un ratio de grille (`2fr 1fr` etc.) : demandé pour que ce bloc, l'encadré "objectifs" du portail et le bloc chiffres clés de `.section-columns` (plus bas) partagent tous la même largeur, plutôt que chacun dérive une largeur différente de son propre ratio selon la largeur du texte voisin. Même palier ("desktop" du projet, 1024px). `align-items: stretch` (pas `start` comme `.section-columns`) : le repli photo n'a pas de hauteur de contenu propre à respecter, autant qu'il occupe toute la hauteur du texte voisin plutôt que de laisser du vide EN DESSOUS de lui. Empilé par défaut (mobile/tablette, ordre DOM texte puis image = déjà correct sans règle supplémentaire). */ @media (min-width: 1024px) { .section-intro-row { display: grid; grid-template-columns: 1fr var(--secondary-column-width); gap: calc(var(--spacing-gutter) * 2); align-items: stretch; } /* Correctif retour utilisateur : `.encadre` (repli `data.introEncadre`, _includes/section.njk) porte `margin: 1rem 0` par défaut (règle de base, plus bas dans ce fichier) -- une fois placé comme 2e colonne de cette grille, ce margin-top décalait son contour vers le bas par rapport au premier paragraphe du texte voisin (qui, lui, n'a aucune marge propre à ce niveau). Neutralisé UNIQUEMENT dans ce contexte (`.section-intro-row > .encadre`, pas `.encadre` globalement -- les encadrés isolés dans un flux de texte classique gardent leur respiration verticale habituelle). Le margin-bottom reste : sans effet ici (dernier/seul enfant de sa cellule de grille), mais s'il devient un jour visible en empilement mobile (ordre DOM texte puis encadré), il fournit l'espacement voulu entre les deux. */ .section-intro-row > .encadre { margin-top: 0; } } /* Repli "photo à venir" générique (`imagePlaceholder()`, _includes/ section.njk) : même langage visuel que la zone décorative des volets (`.volet--photo-zone::after` plus bas -- fond pastel + pictogramme "image"), pour rester cohérent avec l'unique autre repli photo du site. `min-height` : hauteur de secours pour l'empilement mobile/tablette (où `align-items: stretch` ci-dessus ne s'applique pas, rien d'autre ne fixe sa hauteur) -- ignorée sur desktop dès que `.section-intro-row` l'étire à la hauteur du texte voisin. */ .image-placeholder { min-height: 200px; border-radius: var(--rounded); background-color: color-mix(in srgb, var(--section-accent, var(--color-primary)) 20%, white); background-image: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' viewBox='0 0 24 24' fill='none' stroke='rgba(8,67,111,0.4)' stroke-width='1.5' stroke-linecap='round' stroke-linejoin='round'%3E%3Crect x='3' y='3' width='18' height='18' rx='2'/%3E%3Ccircle cx='8.5' cy='8.5' r='1.5'/%3E%3Cpath d='M21 15l-5-5L5 21'/%3E%3C/svg%3E"); background-repeat: no-repeat; background-position: center; background-size: 48px 48px; } .section--secondary .image-placeholder { background-color: color-mix(in srgb, var(--section-accent, var(--color-secondary)) 20%, white); } /* Retour utilisateur ("toutes les zones image prêtes") : variante du repli ci-dessus qui affiche une vraie photo -- pictogramme/teinte pastel neutralisés, même logique que `.volet--photo-zone--image` plus bas (mécanisme jumeau pour les zones décoratives de volet). Règle dédiée pour le cas `.section--secondary` (spécificité égale à `.section --secondary .image-placeholder` sinon -- même précaution que `.volets.volets--etudes`/`.encadre--image` ailleurs). `background-image` n'est PAS posée ici (retour utilisateur, bug sous-dossier) : `imageOrPlaceholder()` (_includes/section.njk) la pose directement en style inline sur l'élément -- une règle ici via `var(--image-placeholder-photo)` résolvait les URL relatives contre CE fichier CSS plutôt que contre la page, cf. son commentaire. */ .image-placeholder.image-placeholder--photo { background-color: transparent; background-size: cover; background-position: center; } .section--secondary .image-placeholder.image-placeholder--photo { background-color: transparent; } /* Retour utilisateur ("travaux-interbranches") : zone image AU-DESSUS du premier paragraphe du texte d'intro (`data.introImageAvant`, cf. `.section-intro` dans _includes/section.njk) -- CONFINÉE à la colonne de texte (1er essai en pleine largeur de la rangée, rejeté : "pas sur deux colonnes"). Ratio large de type bannière plutôt que le `min-height` de secours de `.image-placeholder` (pensé pour une 2e colonne étroite, pas ce contexte pleine largeur de colonne). */ .section-image-avant { margin-block-end: 1.75rem; } .section-image-avant .image-placeholder { aspect-ratio: 21 / 9; min-height: 0; } /* Bandeau de couleur de rôle (FR10) : substitut du hero-band photo (aucune photo disponible pour cette story, cf. Design Notes de la spec 1.3). La couleur de fond réelle (var(--color-primary)/var(--color-secondary)) est posée en style inline par _includes/section.njk selon data.couleur ; ce bloc ne fixe que la mise en forme commune (padding, coins, typo, couleur de texte). */ .section-band { position: relative; overflow: hidden; padding: 1.5rem 1.75rem; border-radius: var(--rounded-md); margin-block-end: 1.75rem; } /* Retour utilisateur ("améliorer les bandeaux" puis "pareil pour les petits headers, plusieurs couleurs ou camaïeu... le header vert on voit rien pour le coup") : 2 halos décoratifs en pseudo-éléments -- pas de markup supplémentaire à porter (purement visuel), même esprit que `.hero__halo` plus haut dans ce fichier. Camaïeu plutôt que teintes fixes (1er essai : sheen blanc + vert de marque fixe) : un halo VERT sur le bandeau "portail", déjà vert (`bandeauVertLogo`), s'y fondait entièrement -- invisible, constaté en navigateur. `color-mix(in srgb, white/black N%, var(--section-band- color))` (posée par `section()`, _includes/section.njk) dérive une teinte plus claire et une plus sombre de la couleur RÉELLE de CE bandeau -- garantit un contraste visible sur N'IMPORTE laquelle des 4 couleurs de bandeau du site (bleu, turquoise, violet, vert du logo), jamais une couleur fixe qui pourrait s'y fondre. Dérive perpétuelle (`@keyframes section-band-halo-drift` plus bas, propre à ce bloc -- amplitude bien plus modeste que les 3 trajectoires du hero, cf. leur commentaire : ces bandeaux sont petits, un mouvement aussi ample que celui du hero les ferait sortir de cadre en permanence) : même exception documentée qu'au hero (cf. son commentaire), même exigence de discrétion -- cycles longs, amplitude faible, `prefers-reduced-motion: reduce` neutralise entièrement (repli `opacity`/position statique ci-dessous). */ /* Retour utilisateur ("fais les mêmes animations sur les bandeaux de section" -> "plus flagrant, je vois à peine un halo bouger et pas les deux autres, on peut en mettre trois sur toute la largeur") : même recette que `.hero__halo` plus haut dans ce fichier -- forme organique (`border-radius` à 8 valeurs, pas un cercle), `mix-blend-mode: overlay`, rotation + dérive. 3 halos désormais (`::before`/`::after` + un vrai 3e élément, `.section-band__halo` -- CSS ne fournit que 2 pseudo-éléments, cf. section.njk), répartis explicitement GAUCHE / CENTRE / DROITE plutôt que tous les 2 blottis dans le même angle (essai précédent : les 2 halos étaient visuellement proches, un seul se remarquait vraiment). Tailles et opacité augmentées (`plus flagrant`) : jusqu'à 62%/460px (contre 60%/340px avant) et opacité remontée (0,7/0,6/0,5). Flou (24px, inchangé) : ces halos restent bien plus petits que ceux du hero, un flou aussi fort que le sien les diluerait entièrement. Couleurs INCHANGÉES (camaïeu clair/sombre dérivé de `--section-band-color`, cf. commentaire plus haut) -- c'est ce qui garantit la visibilité sur les 4 couleurs de bandeau, contrairement au trio fixe du hero. */ .section-band::before, .section-band::after, .section-band__halo { content: ""; position: absolute; pointer-events: none; filter: blur(24px); mix-blend-mode: overlay; } .section-band::before { top: -80%; left: -8%; width: 62%; max-width: 460px; aspect-ratio: 1; background: color-mix(in srgb, white 55%, var(--section-band-color, var(--color-primary))); opacity: 0.7; border-radius: 42% 58% 61% 39% / 45% 48% 52% 55%; } .section-band__halo { bottom: -85%; left: 38%; width: 52%; max-width: 380px; aspect-ratio: 1; background: color-mix(in srgb, white 40%, var(--section-band-color, var(--color-primary))); opacity: 0.6; border-radius: 63% 37% 51% 49% / 39% 58% 42% 61%; } .section-band::after { top: -75%; right: -10%; width: 55%; max-width: 400px; aspect-ratio: 1; background: color-mix(in srgb, black 30%, var(--section-band-color, var(--color-primary))); opacity: 0.5; border-radius: 55% 45% 38% 62% / 62% 40% 60% 38%; } @media (prefers-reduced-motion: no-preference) { .section-band::before, .section-band::after, .section-band__halo { animation-name: section-band-halo-drift; animation-timing-function: ease-in-out; animation-iteration-count: infinite; } /* Retour utilisateur ("augmente la vitesse d'animation x4 dans le bandeau") : durées ET délais divisés par 4 (16/18/20s -> 4/4.5/5s ; -5/-11s -> -1.25/-2.75s) -- diviser aussi les délais, pas seulement les durées, garde le même DÉCALAGE RELATIF entre les 3 halos (donc les mêmes croisements de trajectoires), juste 4x plus vite plutôt que désynchronisés. */ .section-band::before { animation-duration: 4s; } .section-band__halo { animation-duration: 4.5s; animation-delay: -1.25s; } .section-band::after { animation-duration: 5s; animation-delay: -2.75s; } @keyframes section-band-halo-drift { 0% { transform: translate(0, 0) rotate(0deg) scale(1); } 22% { transform: translate(8%, -6%) rotate(25deg) scale(1.15); } 47% { transform: translate(-6%, 5%) rotate(-18deg) scale(0.85); } 68% { transform: translate(5%, 8%) rotate(14deg) scale(1.1); } 100% { transform: translate(0, 0) rotate(360deg) scale(1); } } } .section--primary .section-band { color: var(--color-on-primary); } .section--secondary .section-band { color: var(--color-on-secondary); } /* Retour utilisateur : bandeau "portail" dans le vert du logo (--color-tertiary, posé par bandeauVertLogo -- cf. _includes/section.njk et le commentaire sur VALID_COULEURS dans _data/rapport.js). Règle séparée plutôt qu'un 3e cas dans .section--primary/.section--secondary ci-dessus : `couleur` (donc la classe `section--primary` ici) reste inchangé, seule cette classe additionnelle existe pour corriger le texte. Placée APRÈS .section--primary pour gagner le conflit de spécificité égale (même nombre de classes) via l'ordre de cascade -- `--color-on- tertiary` (sombre) plutôt que le blanc habituel : ce vert clair n'offre pas un contraste suffisant avec du texte blanc. */ .section--vert-logo .section-band { color: var(--color-on-tertiary); } .section-band h2 { margin: 0; color: inherit; /* `position: relative; z-index: 1` : garantit que le titre reste au-dessus des halos décoratifs (`.section-band::before`/`::after` plus haut dans ce fichier) quel que soit l'ordre de peinture des pseudo-éléments par rapport au contenu réel. */ position: relative; z-index: 1; } /* Retour utilisateur ("donner un peu de dynamisme") : la bande "Avant- propos" chevauche le bas du hero -- environ la moitié de sa propre hauteur passe par-dessus le hero, comme une carte qui flotte sur la photo plutôt que de s'enchaîner platement dessous. Scopé au SEUL #avant-propos (1ère section, juste après .hero dans le flux -- aucune autre section n'est adjacente au hero) via id de section, même précédent que `#etudes-de-branches .chiffres-cles-liste` plus bas dans ce fichier. Valeurs empiriques (vérifiées en navigateur) : hauteur réelle de la bande mesurée à 83px sous 768px (police h2 mobile) et 91px à partir de 768px (police h2 desktop, cf. media query juste plus bas dans ce fichier) -- la marge négative vise la moitié de CHAQUE valeur, pas une fraction de la hauteur du hero (`--hero-band-min-height`, sans rapport avec la hauteur de cette bande). `position: relative` + `z-index: 1` : garantit l'empilement au-dessus du hero explicitement plutôt que de dépendre du seul ordre du DOM (fond flex du hero, cf. `.hero` plus haut dans ce fichier). Ombre reprise telle quelle de `.portail-banner__encadre .encadre` (même fichier) -- même traitement "carte qui flotte sur une photo" déjà éprouvé ailleurs sur ce site, pas une nouvelle valeur inventée. Correctif (vérification navigateur) : `main` porte son propre padding- top (`--spacing-margin-mobile`/24px à tout palier -- cf. règle `main` plus haut dans ce fichier, seul `padding-inline` varie par palier) -- sans en tenir compte, la marge négative absorbe d'abord CE padding avant d'entamer le hero, ne laissant qu'un chevauchement de ~24px (23,7% de la bande, mesuré) au lieu de la moitié voulue. `--avant- propos-overlap` (tokens.css, 2.6rem mobile / 2.85rem desktop ci-dessous) porte la moitié de bande voulue (41,5px / 45,6px, mesuré) ; ce token commun ajoute encore le padding de `main` (1.5rem) pour obtenir la marge négative totale -- PARTAGÉ avec `.hero__numeral` plus bas dans ce fichier, qui doit remonter du même montant pour rester lisible malgré ce chevauchement (bug constaté : "2025" partiellement caché sous la bande sans cette synchronisation). */ #avant-propos .section-band { position: relative; z-index: 1; margin-top: calc(-1 * (var(--avant-propos-overlap) + 1.5rem)); box-shadow: 0 8px 24px rgba(8, 67, 111, 0.15); } /* `:root` (pas `#avant-propos .section-band`) : `--avant-propos-overlap` est consommé par 2 éléments SANS lien de parenté DOM (cette bande ET `.hero__numeral`, tous deux enfants de `body` mais ni l'un ni l'autre ancêtre du second) -- une redéfinition scopée à la seule bande ne changerait la valeur QUE pour elle, laissant le numéral désynchronisé à ce palier (`.hero__numeral` continuerait d'hériter 2.6rem de `:root`). */ @media (min-width: 768px) { :root { --avant-propos-overlap: 2.85rem; } } /* Retour utilisateur : éviter les césures (coupure syllabique avec un trait d'union visible) dans les titres -- `hyphens: auto` est posé sur `body` (Story 1.4) et hérité par tous les descendants, y compris les titres. Désactivée ici pour les niveaux de titre uniquement : `overflow-wrap: break-word` (également hérité depuis `body`) reste actif comme filet de sécurité anti-débordement pour un mot long non sécable (ex. "L'accompagnement", "certifications") -- il coupe le mot si nécessaire pour éviter un débordement horizontal, mais sans y insérer de trait d'union, contrairement à `hyphens: auto`. Le correctif Story 1.4 (mot long ne devant jamais élargir le viewport) reste donc garanti, seule la préférence esthétique (pas de "-" visible dans un titre) change. */ h1, h2, h3, h4 { hyphens: none; } /* Chaîne de repli (correctif revue #4) : chaque titre garde son PROPRE token de famille (--font-display-lg-family / -headline-md- / -headline-sm- / -counter-figure-, AD-3 — jamais un token substitué par un autre), mais la chaîne de repli après ce token est désormais alignée sur celle de `body` (system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif) plutôt qu'un `sans-serif` nu, pour une dégradation cohérente si Google Fonts ne charge pas. */ /* Retour utilisateur (revue Sally, party mode) : h2 partageait le token `display-lg` avec h1 (hero), rendant les deux à 48px -- le titre du rapport n'avait alors aucune prééminence sur un titre de chapitre. Passe à `headline-lg` (36px, nouveau palier intermédiaire, cf. tokens.css) -- h1/hero reste inchangé sur `display-lg`. */ h2 { font-family: var(--font-headline-lg-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-headline-lg-size); font-weight: var(--font-headline-lg-weight); line-height: var(--font-headline-lg-line-height); letter-spacing: var(--font-headline-lg-letter-spacing); margin-top: 0; } /* Story 1.4 (FR11) : palier mobile pour h2, nécessaire pour que les titres de section les plus longs ("L'accompagnement sur les certifications et les compétences") ne se réduisent pas à des coupures de mot en cascade dans .section-band (confirmé en vérification navigateur à 360px, cf. Design Notes). overflow-wrap sur body reste la garantie anti-débordement même avec ce token mobile. Retour utilisateur (revue Sally, party mode) : réutilise `--font-headline-md` (28px, déjà existant) plutôt que `display-lg-mobile` (32px) -- h2 est passé sur `headline-lg` en desktop (cf. règle h2 ci-dessus), garder le même token mobile que display-lg (partagé avec h1) aurait juste déplacé la confusion sur mobile plutôt que de la résoudre. 28px reste plus petit que les 32px d'avant, donc au moins aussi sûr vis-à-vis du risque de débordement d'origine. */ @media (max-width: 767px) { h2 { font-size: var(--font-headline-md-size); line-height: var(--font-headline-md-line-height); letter-spacing: var(--font-headline-md-letter-spacing); } } /* Retour utilisateur (capture d'écran de référence) : trait vertical épais dans la couleur d'accent verte (--color-tertiary) devant les titres de groupe -- appliqué au niveau h3 uniquement (jamais h4/.volet__heading, qui reste le titre affiché DANS une carte de volet à côté de son propre picto -- h3 n'est de toute façon jamais utilisé à l'intérieur d'un volet dans ce gabarit, donc pas de garde supplémentaire nécessaire pour respecter "sauf sur les cartes qui ont déjà leur picto"). Couvre les 5 usages de h3 du site (titre de chiffresCles(), etudesTitre, veilleProspective.titre, etudesThematiquesTitre, encadre.titre) de la même façon, sans logique par section. Vert réservé habituellement à la nav/au focus clavier (DESIGN.md : "garder le vert rare et intentionnel") -- ici volontairement étendu par l'utilisateur à un niveau de titre précis et cohérent, pas une utilisation généralisée. */ h3 { position: relative; padding-left: 1.25rem; font-family: var(--font-headline-md-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-headline-md-size); font-weight: var(--font-headline-md-weight); line-height: var(--font-headline-md-line-height); } h3::before { content: ""; position: absolute; left: 0; top: 0.125em; bottom: 0.125em; width: 6px; border-radius: var(--rounded-full); background-color: var(--color-tertiary); } h4 { font-family: var(--font-headline-sm-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-headline-sm-size); font-weight: var(--font-headline-sm-weight); line-height: var(--font-headline-sm-line-height); margin-bottom: 0.25rem; } /* Chapô de section (Story 1.3, correctif revue #1) : token body-lg — défini depuis la création de theme.js/tokens.css mais jusqu'ici jamais référencé par une règle CSS. */ .sous-titre { font-family: var(--font-body-lg-family), system-ui, -apple-system, "Segoe UI", Roboto, Arial, sans-serif; font-size: var(--font-body-lg-size); font-weight: var(--font-body-lg-weight); line-height: var(--font-body-lg-line-height); } p, ul, ol { margin: 0 0 1rem; } ul, ol { padding-left: 1.25rem; } /* Retour utilisateur : puce personnalisée pour les listes à puces du contenu -- asset fourni directement par l'utilisateur (docs/source/ puceobs.png, copié tel quel dans images/puce.png, 43×43px carré) plutôt que le disque par défaut du navigateur. Correctif : la 1re version de cette règle utilisait une forme recadrée depuis le logo -- l'utilisateur a précisé que ça n'avait aucun rapport avec la puce demandée et a fourni le fichier exact à utiliser. Scopé par exclusion des deux seules autres listes du site, qui ont chacune déjà leur propre traitement `list-style: none` pour une raison différente (grille de chiffres clés, menu de navigation horizontal) -- une liste à puces "nue" (`