/* ========================================================================= LE THÈME — et depuis le 8 septembre 2026, LE MOTEUR EN EST LA SOURCE. ⚠️⚠️ CE QUE CE FICHIER N'EST PLUS : la définition des couleurs du site. Elles viennent de `GET /api/salon → apparence`, et la vitrine les pose en variables sur `` (voir App\Service\ApparenceDuSite et les QUATRE gabarits qui portent `data-theme`). Contrat : `docs/api-apparence.md`. ⚠️ CE QUE CE FICHIER EST DEVENU : le REPLI D'UN MOTEUR MUET. Les valeurs ci-dessous sont celles du thème sombre — l'état que le produit a toujours rendu. Une panne d'API laisse donc la page EXACTEMENT comme avant ce lot, au lieu de la rendre sans aucune couleur. C'est le même choix que `marqueEditableIci` absent qui vaut `true` : la seule valeur de repli qui dégrade vers du connu. ⚠️⚠️ ET CE N'EST PAS UNE SECONDE SOURCE : il n'y a ici qu'UN SEUL thème, pas une table. La table des thèmes vit dans le moteur (`App\Enum\ThemeVitrine`) et nulle part ailleurs — parce que c'est lui qui doit REFUSER une couleur d'accent illisible, et qu'il ne peut pas juger un contraste sans connaître le fond contre lequel la couleur sera peinte. ⚠️ LE PRIX EST ASSUMÉ, ET IL FAUT LE SAVOIR EN ARRIVANT ICI : cette feuille NE PEUT PLUS ÊTRE RELUE SEULE pour savoir de quelle couleur est un site. ⚠️ `[data-theme="dore"]` A DISPARU, ET SON NOM ÉTAIT FAUX DEPUIS L'ORIGINE : « doré » décrit l'ACCENT, or c'est précisément l'accent qui devient libre — un salon en noir/bleu se serait retrouvé sous `data-theme="dore"`. Les thèmes s'appellent désormais `sombre` et `clair` : ils nomment le FOND, qui est ce qu'ils portent vraiment. ========================================================================= */ /* ⚠️ PALETTE DE REPLI — surchargée par le serveur quand le moteur répond. Ne pas y ajouter un second thème : voir l'en-tête. */ :root { --c-bg: #121212; --c-bg-elev: #1b1b1b; /* cartes / surfaces surélevées */ --c-bg-elev-2: #242424; /* survol / second niveau */ --c-border: #2e2e2e; --c-text: #f2efe9; --c-text-muted: #a7a29a; /* ⚠️ LES DEUX PILES DE POLICES — repli surchargé par le serveur quand le moteur répond *(la police, 11 septembre 2026)*. ⚠️⚠️ **UNE SEULE PAIRE ICI, PAS UNE TABLE DES SEPT** : c'est exactement le régime de la palette au-dessus. Recopier les sept paires ferait de cette feuille une seconde source sur un dépôt **dupliqué par client**, et c'est celle du gabarit qui gagnerait un jour, sur tous les sites à la fois. La table vit chez le moteur et nulle part ailleurs. */ --police-titre: "Oswald", sans-serif; --police-texte: "Inter", system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; --radius: 10px; --shadow: 0 12px 30px rgba(0, 0, 0, 0.45); --header-h: 80px; /* ⚠️ LA HAUTEUR D'UN ÉCRAN PLEIN, EN POINT UNIQUE — 6 septembre 2026. `calc(100vh - var(--header-h))` était écrit à l'IDENTIQUE à trois endroits de `sections.css` : `.hero`, `.section--soon` et `.section--tunnel`. Trois copies d'une même valeur, donc trois occasions de diverger — et le correctif `svh` ci-dessous aurait été posé sur l'instance qu'on regardait en laissant les deux autres. */ --hauteur-plein-ecran: calc(100vh - var(--header-h)); } /* ⚠️ `100vh` MESURE L'ÉCRAN SANS LA BARRE DU NAVIGATEUR, donc sur téléphone il déborde de ce qu'on VOIT : le bloc est plus haut que la fenêtre, son contenu centré descend, et le bas reste sous la barre. `100svh` est la même mesure prise barre VISIBLE — c'est-à-dire ce que la personne a réellement sous les yeux. ⚠⚠️ L'`@supports` N'EST PAS UNE PRÉCAUTION DÉCORATIVE. Le repli habituel — deux déclarations, la seconde ignorée si elle ne se parse pas — NE MARCHE PAS sur une propriété personnalisée : sa valeur est stockée telle quelle sans être comprise, et un `svh` inconnu n'échoue qu'à l'EMPLOI, où la propriété retombe sur son initiale et non sur la déclaration précédente. On perdrait la hauteur au lieu de la dégrader. ⚠️ SUR UN ÉCRAN DE BUREAU, `svh` ET `vh` SONT ÉGAUX : cette règle ne change rien à ce qui est en ligne aujourd'hui, et c'est voulu — la hauteur du hero au bureau est acceptée telle quelle. ⚠⚠️ `svh` ICI, `dvh` DANS LA MODALE DE L'AGENDA — NE PAS « HARMONISER ». Le lot 27 avait déjà tiré la leçon (`admin.css`, `.agenda-modal__dialog`) et a choisi `dvh` : une modale porte un formulaire, le clavier logiciel mange la place, et le bouton de validation doit RESTER atteignable pendant que la hauteur bouge. Une SECTION de page n'a pas ce besoin et a le défaut inverse : `dvh` la ferait se redimensionner à chaque repli de la barre pendant le défilement, donc reflouer la page sous le doigt. `svh` est la plus PETITE des hauteurs, donc une valeur STABLE : le hero tient à l'écran et ne bouge plus. Deux unités différentes parce que ce sont deux besoins différents. ⚠️ ET LA MÊME RÉSERVE QU'AU LOT 27 : NON ÉPROUVÉ SUR UN APPAREIL RÉEL. Une iframe ou un émulateur de taille n'a pas de barre de navigateur, donc `svh` y vaut `vh` et l'effet y est INVISIBLE par construction. La correction traite la cause nommée et ne peut pas empirer (`svh` ≤ `vh`), mais elle ne se constate que sur un téléphone. */ @supports (height: 100svh) { :root { --hauteur-plein-ecran: calc(100svh - var(--header-h)); } } /* Header plus compact en mobile (logo réduit, voir components.css). */ @media (max-width: 560px) { :root { --header-h: 72px; } } /* ---- Accent de repli, et les deux DÉRIVÉES que le moteur publie ---- */ :root { --c-accent: #c9a14a; --c-accent-hover: #ddb968; --c-accent-contrast: #1a1408; /* texte sur un aplat d'accent */ /* ⚠️⚠️ LES DEUX DÉRIVÉES, ET ELLES NE SE CALCULENT PAS ICI. `--c-accent-texte` atteint 4,5:1 sur les fonds du thème, `--c-accent- interface` atteint 3:1. Le moteur les publie parce que `color-mix()` sait assombrir une couleur mais NE SAIT PAS s'arrêter quand le contraste suffit : c'est une recherche — le mélange le plus fidèle qui atteigne le seuil —, pas une formule. ⚠️ SUR LE THÈME SOMBRE ELLES VALENT L'ACCENT LUI-MÊME, et c'est MESURÉ : `#c9a14a` rend 7,74:1 sur `#121212` et 6,42:1 sur `#242424`. Le repli les pose donc égales — il décrit le thème sombre, et rien d'autre. ⚠️⚠️ NE PAS EN CONCLURE QU'ELLES SONT INUTILES : sur un fond CLAIR le même doré tombe à 2,30:1, sous le seuil le plus permissif. C'est là qu'elles divergent, et c'est là que le site se casserait sans elles. */ --c-accent-texte: #c9a14a; --c-accent-interface: #c9a14a; /* ⚠️⚠️ LES DEUX DÉGRADÉS DU HERO DÉRIVENT DU FOND ET DE L'ACCENT — ils ne les recopient plus. Ils portaient `rgba(18,18,18,…)` et `rgba(201,161,74,…)`, c'est-à-dire `--c-bg` et `--c-accent` réécrits à la main en décimal. Sur un thème CLAIR, ce voile serait resté NOIR : le hero aurait gardé un rideau sombre au milieu d'un site clair, sans qu'aucune règle n'ait l'air fautive. *On corrige l'instance qu'on regarde, pas le défaut — sauf à chercher la valeur dans tout le fichier, ce que ce lot a fait.* ⚠️ `in srgb` EST LA MOITIÉ DE LA PROMESSE : `color-mix()` interpole dans l'espace qu'on lui nomme, et le défaut de CSS (`oklab`) rend des valeurs DIFFÉRENTES de celles que le moteur calcule. */ --hero-overlay: linear-gradient( 180deg, color-mix(in srgb, var(--c-bg) 55%, transparent) 0%, color-mix(in srgb, var(--c-bg) 92%, transparent) 100% ); --hero-tint: radial-gradient( 1200px 500px at 70% -10%, color-mix(in srgb, var(--c-accent) 22%, transparent), transparent 60% ); }