/**
 * Feuille de style du front public (F1, étape 4) — socle seulement.
 *
 * Ce lot ne rend aucun écran : les shortcodes arrivent avec F2 à F5. Cette
 * feuille pose donc ce dont TOUS les écrans dépendront — le conteneur, la
 * typographie de base — et rien de plus. Chaque lot suivant y ajoute ses
 * propres règles.
 *
 * POURQUOI aucune valeur n'est écrite en dur ici : toutes viennent de
 * front-variables.css, dont c'est la seule raison d'être. Une couleur posée
 * directement dans cette feuille échapperait au changement de charte, et ne
 * se verrait qu'à l'œil, sur un écran, un jour.
 *
 * POURQUOI le motif RTL n'est PAS redéfini ici : il vit dans
 * composants-rtl.css, partagé avec les gabarits de visuel (F1, étape 3). Le
 * recopier en ferait une quatrième version — c'est exactement ce que
 * l'extraction a supprimé.
 */

/**
 * ⚠️ LE FOND EST POSÉ ICI PARCE QUE LA COULEUR DE TEXTE L'EST (T5.49).
 *
 * Avant ce ticket, cette règle déclarait `color` et PAS `background` : le
 * plugin décidait une moitié du couple et laissait l'autre au thème. Tant que
 * le thème est clair, l'accident est heureux et rien ne se voit. MESURÉ sur la
 * page réelle en simulant un fond sombre, sans toucher à la couleur du texte :
 * le contraste tombe à 1,13:1 sur #171717 et 1,30:1 sur #030303 — le fond de
 * la charte du designer — sur 20 éléments, soit tout le corps des tableaux.
 * Invisible, pas seulement inconfortable.
 *
 * La mesure a aussi ISOLÉ la cause, et c'est ce qui rend ce correctif sûr :
 * les couples dont le plugin posait DÉJÀ les deux moitiés — #f6f7f7 des
 * en-têtes, #006030 des boutons — restent à 6,83:1 et 7,20:1 sur n'importe
 * quel thème. Ce n'est donc pas la palette qui était fragile, c'est le couple
 * à moitié décidé.
 */
/* ⚠️ `.pst-front` NE PEINT PLUS RIEN (T5.57). Elle ne porte que la base
   typographique et directionnelle, commune à TOUS les blocs du front — ceux
   qui portent du texte comme les enveloppes autour d'une image ou d'un
   gabarit.

   Le couple couleur/fond a déménagé tel quel dans `.pst-front--surface`
   ci-dessous. POURQUOI : depuis T5.49, cette règle-ci posait `color` et
   `background` ensemble, ce qui est juste pour un texte — il n'a pas de
   couleur décidable sans fond connu — et faux pour une enveloppe autour d'une
   surface OPAQUE, qui peint la sienne. Le fond n'y peignait que le jour laissé
   sous l'image par le `display: inline` / `vertical-align: baseline` du thème :
   5 px mesurés, invisibles sur un thème clair, bande claire sur un thème
   sombre. */
.pst-front {
	font-family: var( --pst-police );
	font-size: var( --pst-taille-base );
	direction: rtl;
}

/* Le couple couleur/fond, porté par les seuls blocs qui PORTENT DU TEXTE
   (T5.57) : détails, tableaux, message de liste vide, filtres, et les champs
   composés de `[pst_champ]`.

   ⚠️ C'EST ICI QUE VIT LA GARANTIE DE CONTRASTE DE T5.49, et elle n'a pas été
   affaiblie par le déplacement : les 144 couples ont été re-mesurés à
   l'identique — 4 blocs × 2 palettes × 2 thèmes × 380/768/1280 px × LTR/RTL.
   Un seul sélecteur la porte, donc un seul endroit à re-mesurer au prochain
   lot ; la disperser sur `.pst-detail`, `.pst-front__conteneur` et les autres
   aurait multiplié les endroits où elle peut se perdre.

   ⚠️ POURQUOI LES DEUX MOITIÉS SONT INSÉPARABLES, et pourquoi elles sont
   écrites dans la même règle : poser `color` sans `background` est exactement
   le défaut que T5.49 a corrigé — le texte devient illisible dès que le thème
   ne fournit pas le fond attendu. Ne jamais en déplacer une sans l'autre. */
.pst-front--surface {
	color: var( --pst-couleur-texte );
	background: var( --pst-couleur-fond );
}

.pst-front__titre {
	font-size: var( --pst-taille-titre );
	color: var( --pst-couleur-primaire );
	margin: 0 0 var( --pst-espace-m );
}

/**
 * POURQUOI une largeur maximale en `%` et non en pixels : le front s'insère
 * dans une page du thème, dont on ne connaît pas la largeur de contenu.
 * Imposer une valeur absolue déborderait sur les thèmes étroits — et la
 * consigne « aucune dépendance à un thème » interdit de supposer la sienne.
 */
.pst-front__conteneur {
	max-width: 100%;
	overflow-x: auto;
}

/**
 * Le trait des matchs annulés (F3, étape 4).
 *
 * ⚠️ POURQUOI CE POURQUOI EST ÉCRIT ICI ET NON RECOPIÉ DES VISUELS. Le motif
 * est le même que celui de `admin/templates-visuel/assets/promo13.css`
 * (T1.11) — mais sa justification, elle, ne l'est PAS. Là-bas, elle dit : « ce
 * gabarit n'est jamais consulté comme une page, le seul moteur qui le rende est
 * celui qui le capture », ce qui rendait sans objet le grief de compatibilité
 * entre navigateurs. Une page publique est consultée par des navigateurs
 * quelconques, mobile compris : cette phrase y serait FAUSSE, et la recopier
 * aurait importé une justification périmée sous couvert de réutiliser un motif.
 *
 * POURQUOI `position: relative` sur un `<tr>`, malgré sa réputation. MESURÉ,
 * pas supposé — procès-verbal : recette/F3-mesure-trait-matchs-annules.md.
 * Blink (Chrome 151.0.7922.138) : le pseudo-élément fait 637,25 px pour une
 * ligne de 637,25 px, soit une couverture de 1,000. Gecko (Firefox 153.0.4),
 * sur les PIXELS produits : deux traits de 638 px et 2 px d'épaisseur, et
 * aucun sur les onze lignes non annulées.
 *
 * ⚠️ CE QUE LA MESURE NE COUVRE PAS : WebKit (Safari, et donc tout navigateur
 * sur iOS) n'a été mesuré par personne — aucun moteur WebKit n'est disponible
 * sur la machine de développement. Le verdict ci-dessus ne s'y étend pas.
 *
 * POURQUOI `text-decoration: line-through` reste écarté (acquis du 2026-08-12,
 * non re-mesuré ici) : il ne barre que les glyphes et laisse des trous entre
 * les cellules et sur les colonnes vides.
 *
 * ⚠️ `position: relative` sur la ligne N'EST PAS DÉCORATIVE : sans elle, le
 * pseudo-élément se positionne par rapport au bloc conteneur initial. Mesuré
 * par mutation dans Blink : la largeur passe de 637,25 px à 747 px et la
 * couverture de 1,000 à 1,172 — le trait déborde du tableau. La classe, elle,
 * reste posée et le trait reste rouge : un contrôle qui vérifierait la présence
 * de la classe n'y verrait RIEN (règle anti-mutations 10).
 */
/*
 * ⚠️ LA RÈGLE A DÉMÉNAGÉ DANS `assets/css/composants-rtl.css` À T5.74, et le
 * POURQUOI ci-dessus reste ici parce qu'il est PROPRE AU FRONT — il dit
 * pourquoi `position: relative` sur un `<tr>` tient dans des navigateurs
 * quelconques, mobile compris, ce dont une page de gabarit n'a que faire.
 *
 * Ce qui a bougé : le trait droit est devenu une onde manuscrite, et il n'en
 * existe plus qu'un exemplaire pour le front ET les visuels. Il en existait
 * trois, dont deux à 3px et celui-ci à 2px, sans que rien ne motive l'écart.
 * `composants-rtl.css` est une dépendance déclarée de cette feuille
 * (`Assets_Front::enregistrer()`), donc toujours imprimée avant elle.
 *
 * ⚠️ NE PAS REDÉCLARER LE DÉCOR ICI pour « le rapprocher de son POURQUOI » :
 * ce serait rouvrir la quatrième copie que l'extraction F1 a fermée.
 */

.pst-front__vide {
	color: var( --pst-couleur-texte-vide );
	background: var( --pst-couleur-fond-attenue );
	border: 1px solid var( --pst-couleur-bordure );
	border-radius: var( --pst-rayon-m );
	padding: var( --pst-espace-m );
}

/* ------------------------------------------------------------------
 * F9 — l'habillage. Structurel seulement : la charte n'est pas livrée.
 * ------------------------------------------------------------------ */

/**
 * Les tableaux (listes et matchs).
 *
 * ⚠️ CE QUI EST INTERDIT ICI, ET POURQUOI. Aucune règle de ce bloc ne pose de
 * `transform`, de `filter`, de `perspective`, de `contain` ni de
 * `will-change` — ni sur `.pst-liste`, ni sur ses ancêtres. Ces propriétés
 * créent un NOUVEAU BLOC CONTENEUR, et le pseudo-élément du trait des matchs
 * annulés s'y recalerait : mesuré sous mutation à F3 étape 4, la largeur passe
 * de 637,25 px à 747 px et la couverture de 1,000 à 1,172 — le trait déborde
 * du tableau. **Le défaut est invisible dans le balisage** : la classe reste
 * posée, le trait reste rouge. Les deux mesures de F3 sont rejouées à la fin
 * de ce lot pour cette raison.
 *
 * POURQUOI `border-collapse: collapse` : c'est le CORRECTIF du chevauchement
 * constaté en recette sur la ligne d'en-têtes. Sans lui, chaque cellule porte
 * sa propre bordure et l'espacement par défaut du navigateur s'y ajoute — les
 * en-têtes se recouvrent dès que le texte est plus large que la colonne.
 *
 * POURQUOI `width: 100%` et non une largeur automatique : un tableau
 * auto-dimensionné se colle au bord de son conteneur en RTL, ce que la recette
 * a relevé. Occuper la largeur disponible le recentre sans rien imposer.
 */
.pst-liste {
	width: 100%;
	border-collapse: collapse;
	/* ⚠️ LE PLUGIN SE PRONONCE AUSSI SUR LA BORDURE DE LA TABLE (T5.59). Il n'en
	   déclarait aucune : un thème qui encadre les tableaux qu'il héberge posait
	   donc la sienne sans contradicteur.

	   ⚠️ BORNE MESURÉE, ET ELLE EST ASSUMÉE : cette déclaration ne l'emporte pas
	   sur Divi. `.pst-liste` pèse (0,0,1,0) quand
	   `.entry-content table:not(.variations)` pèse (0,0,2,1) — le `:not()`
	   compte son argument. La contredire demanderait de monter la spécificité,
	   ce que l'arbitrage de T5.59 exclut : un thème qui encadre ses tableaux
	   fait son travail. Le plugin dit son intention et la laisse céder ; ce
	   qu'il GARANTIT, ce sont ses filets et ses couleurs de palette. */
	border: 0;
	text-align: start;
}

/**
 * POURQUOI une largeur MINIMALE sur le tableau, et pourquoi elle est la pièce
 * maîtresse du responsive. `.pst-front__conteneur` porte `overflow-x: auto`
 * depuis F1 — mais un tableau qui se comprime jusqu'à l'illisible ne déclenche
 * jamais ce défilement : il rétrécit ses colonnes à l'infini, et les noms
 * d'équipes se replient lettre par lettre. La largeur minimale est ce qui
 * FORCE le débordement, donc le défilement du conteneur.
 *
 * ⚠️ ET LE DÉFILEMENT DOIT ÊTRE CELUI DU CONTENEUR, JAMAIS CELUI DE LA PAGE.
 * Un débordement non contenu ferait défiler tout le document — vers la droite
 * en RTL, c'est-à-dire du mauvais côté et sur toute la page, y compris
 * l'en-tête du thème. C'est mesuré, pas supposé : voir le procès-verbal de ce
 * lot.
 */
.pst-liste {
	min-width: var( --pst-largeur-min-tableau );
}

/**
 * ⚠️ `text-align: right` ET NON `start` — corrigé le 2026-08-21, même mécanisme
 * que `.pst-detail__liste dd` : voir son POURQUOI, qui porte l'explication
 * complète.
 *
 * En deux mots : chaque cellule porte `dir="auto"`, et une cellule qui ne
 * contient que des chiffres n'a AUCUN caractère fortement directionnel — le
 * navigateur y retombe sur `ltr`, où `start` vaut « gauche ». Mesuré sur les
 * trois familles de page (détail de grille, listes publiques, détail JOCK7) :
 * les cellules arabes étaient à droite, les numériques à gauche, avec la MÊME
 * déclaration `text-align: start`.
 *
 * POURQUOI les en-têtes sont visés par la même règle alors qu'ils étaient déjà
 * corrects : leur libellé est arabe aujourd'hui, donc `rtl` par déduction. Les
 * laisser en `start` ferait dépendre leur alignement du CONTENU — un en-tête
 * réglé en chiffres, ou vidé, basculerait à gauche sans que rien ne le
 * signale. Une seule règle pour les deux supprime cette dépendance.
 */
.pst-liste th,
.pst-liste__cellule {
	padding: var( --pst-espace-s ) var( --pst-espace-m );
	/* ⚠️ LE PLUGIN SE PRONONCE SUR LES QUATRE CÔTÉS (T5.59), PAS SUR LE SEUL
	   BAS. Il n'avait aucune règle mentionnant `border-top` — 0 occurrence —,
	   et un thème qui en pose un le gardait : rien ne peut gagner un débat
	   qu'on ne tient pas. Le raccourci remet les quatre côtés à zéro, puis la
	   ligne suivante déclare le seul que ce tableau veut.

	   ⚠️ ET CETTE DÉCLARATION-CI NE SUFFIT PAS FACE À DIVI, c'est assumé :
	   `.pst-liste__cellule` pèse (0,0,1,0) contre (0,0,1,2) pour
	   `.entry-content tr td`. Elle dit l'intention du plugin et l'emporte sur
	   un thème qui déclare moins fort ; le style « Sans bordures », lui, gagne
	   par sa propre règle, qui pèse déjà deux classes. */
	border: 0;
	border-bottom: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure-attenuee );
	text-align: right;
}

.pst-liste thead th {
	background: var( --pst-couleur-fond-entete );
	font-size: var( --pst-taille-petite );
	white-space: nowrap;
}

/**
 * ⚠️ LA COULEUR DU TEXTE D'EN-TÊTE, ET ELLE SEULE, EST DISPUTÉE AU THÈME (T5.60).
 *
 * POURQUOI elle a quitté la règle ci-dessus. `.pst-liste thead th` pèse
 * (0,0,1,2) — une classe, deux types. Un thème qui vise ses en-têtes par
 * `.entry-content thead th` pèse EXACTEMENT PAREIL : le départage se fait alors
 * à l'ordre de chargement, et le thème, enfilé après les extensions, gagne.
 * Mesuré sous Divi — feuilles publiques relevées sur grilles-pst.tn, annonçant
 * `Version: 4.27.8` ; la version installée sur le site de dev n'est pas
 * établie, et le numéro « 4.9.97.42 » qui figurait ici jusqu'au 2026-09-08 ne
 * l'était pas non plus (T5.61). Les libellés passaient au gris `#555`, soit
 * **2,67:1** sur la bande sombre du plugin, contre 13,54:1 sans le thème. Le
 * seuil de WCAG 1.4.3 est 4,5:1 — ce sont les libellés de colonnes, sans
 * lesquels le tableau ne se lit pas.
 *
 * ⚠️ EN PALETTE CLAIRE LE MÊME GRIS TENAIT 6,95:1, et c'est ce qui rend le
 * défaut si facile à manquer : il ne se voit que dans une palette, et seulement
 * sous un thème. Le site de test n'est pas sous Divi ; le rendu y est identique
 * avant et après ce correctif.
 *
 * ⚠️ CE SÉLECTEUR N'EST PAS UNE ESCALADE. Il pèse (0,0,2,0) par le seul fait
 * d'être deux classes — le mécanisme exact par lequel
 * `.pst-liste--sans-bordures .pst-liste__cellule` l'emporte depuis T5.59.
 * Aucun `!important` ; aucun sélecteur allongé pour le poids.
 *
 * ⚠️ ET IL NE DÉCLARE QUE `color`, délibérément. Le `padding` et la typographie
 * de l'en-tête — graisse, alignement — restent au thème : c'est l'arbitrage du
 * porteur, « laisser le thème habiller ». Ajouter ici la moindre autre
 * propriété étendrait la dispute au-delà de ce qui a été décidé.
 */
.pst-liste .pst-liste__entete {
	color: var( --pst-couleur-texte-entete );
}

/**
 * Les colonnes étroites — numéro d'ordre, buts, résultat, GG/NG, rang.
 *
 * POURQUOI une largeur imposée ICI et nulle part ailleurs : ces colonnes
 * portent un chiffre ou deux caractères. L'algorithme automatique leur donne
 * la même part qu'aux noms d'équipes, qui sont alors comprimés. Les noms, eux,
 * gardent la largeur automatique — leur imposer une valeur tronquerait des
 * chaînes de longueurs très inégales.
 *
 * POURQUOI `nth-child` plutôt qu'une classe par colonne : le balisage est
 * produit par `Rendu_Liste`, gabarit PARTAGÉ qui ne connaît ni grille ni
 * match. Lui faire porter des classes sémantiques par colonne l'obligerait à
 * connaître le domaine — exactement ce que sa conception écarte.
 */
.pst-liste th:first-child,
.pst-liste td:first-child {
	width: var( --pst-largeur-colonne-etroite );
}

.pst-liste__lien {
	color: inherit;
	text-decoration: none;
	display: block;
}

.pst-liste__ligne:hover {
	background: var( --pst-couleur-fond-survol );
}

.pst-liste__page {
	margin-top: var( --pst-espace-m );
}

/**
 * Le détail — séparation des blocs.
 *
 * POURQUOI une marge et un filet plutôt qu'un encadré par bloc : la recette a
 * relevé qu'AUCUNE séparation n'existait, les blocs se suivant sans respiration.
 * Un cadre par bloc ferait de chacun une boîte, ce qui hache une page dont les
 * parties se lisent à la suite. Un filet dit « la section précédente est
 * finie » sans découper.
 *
 * POURQUOI le dernier bloc n'en porte pas : un filet en bas de page annonce
 * une suite qui n'existe pas.
 */
.pst-detail__entete,
.pst-detail__matchs,
.pst-detail__cagnotte,
.pst-detail__supplementaires,
.pst-detail__gagnants,
.pst-detail__visuels {
	margin-bottom: var( --pst-espace-l );
	padding-bottom: var( --pst-espace-l );
	border-bottom: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure );
}

.pst-detail > :last-child {
	margin-bottom: 0;
	padding-bottom: 0;
	border-bottom: 0;
}

/**
 * Les listes de définitions du détail.
 *
 * ⚠️ CORRECTIF DU CONSTAT DE RECETTE : « l'écart entre libellé et valeur est
 * très grand — les deux se retrouvent aux extrémités opposées de la ligne ».
 * Un `<dl>` sans mise en page laisse le thème décider, et beaucoup de thèmes le
 * traitent en deux colonnes justifiées. La grille ci-dessous fixe la largeur du
 * libellé et laisse la valeur commencer juste après.
 *
 * POURQUOI `grid` et non `flex` : chaque paire libellé/valeur doit s'aligner
 * verticalement avec les autres. En `flex`, chaque ligne calcule sa propre
 * largeur de libellé, et la colonne des valeurs se met à onduler.
 *
 * POURQUOI la largeur du libellé est en `em` : elle doit suivre la taille du
 * texte, que la charte fera peut-être varier. En pixels, elle deviendrait
 * fausse au premier changement de police.
 */
.pst-detail__liste {
	display: grid;
	grid-template-columns: var( --pst-largeur-libelle ) 1fr;
	gap: var( --pst-espace-xs ) var( --pst-espace-m );
	margin: 0;
}

/**
 * ⚠️ LE LIBELLÉ DÉCLARE SON ALIGNEMENT (T5.62), ET C'EST TOUT L'OBJET DE CETTE
 * RÈGLE — le reste y était déjà.
 *
 * POURQUOI il faut le déclarer alors que « ça marchait ». Sans déclaration, le
 * `dt` prenait la valeur INITIALE `start`, résolue contre le `direction: rtl`
 * que `.pst-front` pose sans condition : « droite », par chance. Une valeur
 * qu'on ne déclare pas est une valeur qu'on ne défend pas — **c'est le mode C
 * de T5.59, et rien ne peut gagner un débat qu'on ne tient pas.**
 *
 * ⚠️ CE QUI REMPLIT LE VIDE, MESURÉ : `.et_pb_module.et_pb_text_align_center`,
 * la classe que Divi pose sur un module réglé sur « texte centré ». Le `dt` en
 * HÉRITE — 140 px de décalage à 380 px, le `dd` restant à droite puisque
 * T5.61 le déclare. Le libellé et sa valeur se retrouvent de deux côtés
 * différents. Divi offre aussi `-phone` et `-tablet` : un module peut n'être
 * centré QUE sur téléphone, et le défaut n'exister que là.
 *
 * ⚠️ AUCUNE ESCALADE N'EST NÉCESSAIRE, et c'est le point qu'on croit devoir
 * discuter : `.et_pb_module.et_pb_text_align_center` pèse (0,0,2,0) contre
 * (0,0,1,1) ici — mais elle vise un ANCÊTRE. **Une valeur héritée cède devant
 * n'importe quelle déclaration directe, quelle que soit sa spécificité.** Il
 * suffit de parler. Aucun `!important`, aucun sélecteur allongé.
 *
 * ⚠️ ET LA VALEUR EST `right`, PAS `start` — mesuré, pas déduit. Le `dt` porte
 * `dir="auto"` exactement comme le `dd` (voir le POURQUOI complet sur
 * `.pst-detail__liste dd`, qui porte l'explication du mécanisme). Un libellé de
 * donnée supplémentaire n'est astreint à aucun alphabet : « Sponsor », sans
 * caractère fortement directionnel arabe, résout `ltr`, et `start` y vaut
 * GAUCHE. Témoin mesuré à 380 px : 255 px de décalage, **sur le site de test,
 * sans aucun thème** — un second défaut, latent depuis F12, que cette même
 * déclaration referme.
 */
.pst-detail__liste dt {
	color: var( --pst-couleur-texte-attenue );
	font-size: var( --pst-taille-petite );
	text-align: right;
}

/**
 * ⚠️ POURQUOI `text-align: right` ICI, ET POURQUOI CE N'EST PAS UNE DIRECTION
 * DE TEXTE — mesuré le 2026-08-21, pas déduit.
 *
 * Constat : les libellés (`dt`) sont à droite, les valeurs (`dd`) restent à
 * GAUCHE. Ce n'est ni un oubli de règle ni une règle qui ne mord pas — c'est
 * `dir="auto"`, que le gabarit pose sur chaque valeur.
 *
 * `dir="auto"` fait déduire la direction du PREMIER CARACTÈRE FORTEMENT
 * DIRECTIONNEL du contenu. Une valeur comme `860` ou `5 001 000,000` n'en
 * contient AUCUN — les chiffres sont neutres — et le navigateur retombe alors
 * sur `ltr`. `text-align: start`, qui vaut « droite » dans un bloc RTL, y résout
 * donc à GAUCHE. Mesuré : `dt` → `direction: rtl`, `dd` numérique →
 * `direction: ltr`, les deux avec le même `text-align: start`.
 *
 * ⚠️ ET LE DÉFAUT NE TOUCHE PAS QUE LES NOMBRES, ce qu'une correction visant
 * « les montants » aurait manqué. La date arabe (`الإثنين 3 أوت 2026`) est
 * elle aussi en `ltr` : son texte vit dans un `<span dir="rtl">` enfant, et un
 * élément portant sa PROPRE direction est exclu du calcul `auto` du parent —
 * qui ne trouve donc, là encore, aucun caractère fort. C'est le MÉCANISME qui
 * est corrigé ici, pas une catégorie de contenu.
 *
 * ⚠️ POURQUOI PAS `direction: rtl` SUR LA VALEUR. Un nombre s'écrit toujours de
 * gauche à droite en interne : `5 001 000,000` doit rester `5 001 000,000`.
 * Forcer la direction déplacerait le séparateur de milliers et un éventuel
 * signe. Ce qui doit changer est le BORD contre lequel le bloc est posé — un
 * alignement, jamais une direction. `dir="auto"` reste donc en place, et fait
 * son travail : rendre correctement un contenu mixte.
 *
 * POURQUOI `right` PLUTÔT QUE `end`, malgré la préférence logique de cette
 * feuille. `end` se résout dans la direction de L'ÉLÉMENT — c'est-à-dire `ltr`
 * ici, donc « droite » par accident sur les nombres et « gauche » sur l'arabe :
 * l'inverse exact du besoin. Le bord voulu est celui du BLOC qui contient, et
 * `.pst-front` déclare `direction: rtl` sans condition (D5, le front est en
 * arabe). `right` EST donc le bord de début, de façon stable.
 */
.pst-detail__liste dd {
	margin: 0;
	text-align: right;
}

.pst-detail__echeance,
.pst-detail__annonce {
	color: var( --pst-couleur-texte-attenue );
	margin: var( --pst-espace-s ) 0;
}

/**
 * Le bloc de remplacement d'un visuel absent.
 *
 * ⚠️ POURQUOI IL REPREND L'HABILLAGE DE L'ÉTAT VIDE plutôt que d'en avoir un.
 * Les deux disent la même chose au lecteur — « rien ici, et ce n'est pas une
 * panne ». Deux cadres d'attente qui se ressembleraient à peu près seraient
 * pires qu'un seul : le visiteur y lirait une différence qui n'existe pas.
 *
 * POURQUOI la variante est affichée en dessous et atténuée : elle nomme CE
 * QU'ON ATTEND. Au même niveau que le message, elle se lirait comme une
 * seconde phrase ; atténuée, elle se lit comme une précision.
 */
.pst-detail__visuel-attendu {
	color: var( --pst-couleur-texte-attenue );
	background: var( --pst-couleur-fond-attenue );
	border: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure );
	border-radius: var( --pst-rayon-m );
	padding: var( --pst-espace-m );
	margin: 0 0 var( --pst-espace-m );
}

.pst-detail__visuel-variante {
	display: block;
	font-size: var( --pst-taille-petite );
	margin-top: var( --pst-espace-xs );
}

.pst-detail__visuel {
	margin: 0 0 var( --pst-espace-m );
}

.pst-detail__visuel img {
	max-width: 100%;
	height: auto;
	border-radius: var( --pst-rayon-s );
}

/**
 * Le lien de téléchargement du visuel (F4.b), habillé à F9.1.b.
 *
 * POURQUOI `--pst-couleur-primaire` plutôt qu'un langage de couleur propre à
 * ce lien : c'est déjà la couleur d'ACTION de ce front — celle du titre
 * (`.pst-front__titre`) — et ce lien en est une. Lui inventer sa propre
 * couleur aurait ajouté une variante de plus à harmoniser le jour où la charte
 * arrive, pour un élément qui n'a aucune raison de se distinguer des autres
 * actions du plugin.
 */
.pst-detail__visuel-telecharger {
	display: inline-block;
	margin-top: var( --pst-espace-s );
	color: var( --pst-couleur-lien );
}

.pst-detail__visuel-telecharger:hover {
	color: var( --pst-couleur-lien-survol );
}

/**
 * ⚠️ LE PREMIER INDICATEUR DE FOCUS CLAVIER DE TOUT LE FRONT (F9.1.b).
 *
 * Mesuré avant ce commit : `front.css` ne contenait AUCUNE règle `:focus` ni
 * `:focus-visible`. Ce n'est donc pas un ajustement d'une convention
 * existante — c'est cette convention qui naît ici.
 *
 * POURQUOI LA RÈGLE PORTE SUR `.pst-front a`, ET NON SUR
 * `.pst-detail__visuel-telecharger` SEULE. Un indicateur posé sur ce seul lien
 * laisserait `.pst-liste__lien` — déjà navigable au clavier, sur CHAQUE ligne
 * de CHAQUE liste publique — sans aucun indicateur de focus. Le poser une
 * seule fois, au niveau du conteneur du plugin, couvre les deux sans créer une
 * seconde liste de sélecteurs à tenir à jour à chaque lien futur.
 *
 * POURQUOI `:focus-visible` et non `:focus` : `:focus-visible` ne s'active
 * qu'au clavier (tabulation), jamais au clic — un contour permanent au clic
 * sur `.pst-liste__lien`, dont `display: block` couvre toute la ligne, serait
 * une gêne visuelle à chaque interaction à la souris, pour un signal dont
 * seul le clavier a besoin.
 *
 * POURQUOI UNE COULEUR QUI NE SERT À RIEN D'AUTRE : le contour ne doit jamais
 * être confondu avec le contenu qu'il entoure. Une couleur déjà portée par le
 * texte environnant (`--pst-couleur-lien`, utilisée juste au-dessus) rendrait
 * le contour moins visible sur les liens qu'il doit précisément signaler.
 *
 * ⚠️ CE RÔLE A SA PROPRE VARIABLE DEPUIS T5.49 : `--pst-couleur-focus`, et non
 * plus `--pst-couleur-accent` dont il empruntait la valeur. Emprunter liait
 * deux décisions sans rapport — le jour où l'accent change pour des raisons de
 * charte, l'indicateur de focus aurait suivi sans que personne ne l'ait voulu.
 * Sa valeur vient de la maquette du designer (#f2d27a, arbitrage T5.49).
 *
 * ⚠️ NE JAMAIS RETIRER CETTE RÈGLE SANS LA REMPLACER : un front sans indicateur
 * de focus est inutilisable au clavier, et le défaut est invisible à la
 * souris — donc invisible en recette si personne ne tabule.
 */
.pst-front a:focus-visible {
	outline: var( --pst-epaisseur-focus ) solid var( --pst-couleur-focus );
	outline-offset: var( --pst-decalage-focus );
}

/**
 * ⚠️ LA RÈGLE CI-DESSUS NE COUVRAIT QUE LES ANCRES — étendue par F11.c, et il
 * fallait le MESURER pour le savoir. `.pst-front a:focus-visible` ne s'applique
 * à aucun `<input>`, `<select>` ni `<button>` : les contrôles de filtres
 * arrivaient donc SANS indicateur de focus clavier, sur un front qui venait
 * précisément d'en faire une convention. Le défaut aurait été invisible à la
 * souris, donc invisible en recette si personne ne tabule — c'est mot pour mot
 * le POURQUOI que F9.1.b avait écrit pour justifier la règle d'origine.
 *
 * POURQUOI ÉTENDRE LE SÉLECTEUR PLUTÔT QUE D'ÉCRIRE UNE SECONDE RÈGLE avec les
 * mêmes déclarations : deux règles porteraient le même contour à deux endroits,
 * et le jour où la charte fixera son épaisseur ou sa teinte, l'une des deux
 * serait ajustée sans l'autre. C'est la liste parallèle que ce projet traque
 * (`docs/NOTE-LISTES-PARALLELES.md`), à l'échelle d'une feuille de style.
 */
.pst-front input:focus-visible,
.pst-front select:focus-visible,
.pst-front button:focus-visible {
	outline: var( --pst-epaisseur-focus ) solid var( --pst-couleur-focus );
	outline-offset: var( --pst-decalage-focus );
}

/* ------------------------------------------------------------------
 * F11.c — l'habillage des filtres interactifs.
 * ------------------------------------------------------------------ */

/**
 * ⚠️ AUCUNE VALEUR EN DUR — contrainte de F9, tenue ici sans exception. Les
 * neuf déclarations de ce bloc n'emploient que des variables existantes de
 * `front-variables.css` : aucune n'a été ajoutée pour ce lot, ce qui vaut aussi
 * garantie que l'habillage suivra la charte le jour où elle sera livrée.
 *
 * POURQUOI `flex-wrap: wrap` PLUTÔT QU'UNE GRILLE À COLONNES FIXES. Le nombre
 * de contrôles VARIE d'un rendu à l'autre — de trois à zéro selon ce que les
 * attributs fixent (critère 11) et selon le domaine (JOCK7 n'en a qu'un). Une
 * grille déclarée pour trois colonnes laisserait des vides là où un attribut a
 * retiré un contrôle. Le flex s'adapte à ce qui reste, sans que la feuille ait
 * à connaître les combinaisons.
 *
 * POURQUOI `align-items: end` : les contrôles portent une étiquette au-dessus,
 * de hauteur égale, mais le bouton n'en a pas. Aligner sur la fin met sa base
 * au niveau de celle des champs plutôt qu'au niveau des étiquettes.
 */
.pst-filtres {
	display: flex;
	flex-wrap: wrap;
	align-items: end;
	gap: var( --pst-espace-m );
	margin-bottom: var( --pst-espace-m );
	padding: var( --pst-espace-m );
	background: var( --pst-couleur-fond-attenue );
	border: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure );
	border-radius: var( --pst-rayon-m );
}

/**
 * POURQUOI l'étiquette est un BLOC au-dessus de son contrôle, et non à côté :
 * en RTL comme en LTR, une étiquette placée au-dessus n'a pas besoin d'une
 * largeur fixe pour rester lisible. `--pst-largeur-libelle` existe et sert
 * ailleurs, mais l'imposer ici tronquerait « تاريخ السحب » sans le dire.
 */
.pst-filtres__champ {
	display: flex;
	flex-direction: column;
	gap: var( --pst-espace-xs );
}

.pst-filtres__champ label {
	font-size: var( --pst-taille-petite );
	color: var( --pst-couleur-texte-attenue );
}

/**
 * POURQUOI les deux types de contrôle partagent une seule règle : un champ de
 * saisie et une liste déroulante doivent avoir la même hauteur et la même
 * bordure, sinon la barre de filtres paraît bricolée. Les déclarer ensemble est
 * ce qui garantit qu'ils ne divergeront pas.
 */
.pst-filtres__champ input,
.pst-filtres__champ select {
	padding: var( --pst-espace-s );
	font-family: inherit;
	font-size: var( --pst-taille-petite );
	color: var( --pst-couleur-texte-champ );
	background: var( --pst-couleur-fond-champ );
	border: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure-champ );
	border-radius: var( --pst-rayon-s );
	min-height: var( --pst-hauteur-cible );
}

/**
 * POURQUOI `display: flex` DEPUIS F11.d : le bouton ne porte plus un mot mais
 * une icône ET un texte masqué. Sans flex, la boîte du texte masqué —
 * positionné en absolu, donc hors flux — laisserait le bouton se dimensionner
 * sur la seule icône, dont la hauteur intrinsèque est nulle tant que le CSS
 * n'est pas appliqué. Le flex donne au bouton une ligne de base stable.
 */
.pst-filtres__valider {
	display: flex;
	align-items: center;
	justify-content: center;
	padding: var( --pst-espace-s ) var( --pst-espace-m );
	font-family: inherit;
	font-size: var( --pst-taille-petite );
	color: var( --pst-couleur-texte-bouton );
	background: var( --pst-couleur-fond-bouton );
	border: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-fond-bouton );
	min-height: var( --pst-hauteur-cible );
	border-radius: var( --pst-rayon-s );
	cursor: pointer;
}

/**
 * ⚠️ AUCUNE COULEUR ICI — l'icône hérite de `currentColor`, lui-même fixé par
 * la règle ci-dessus. Une teinte déclarée sur l'icône serait une SECONDE
 * couleur de bouton, à tenir d'accord avec la première le jour de la charte.
 */
.pst-filtres__icone {
	width: var( --pst-taille-icone );
	height: var( --pst-taille-icone );
	flex: none;
}

/**
 * ⚠️ LE MASQUAGE VISUEL QUI NE RETIRE PAS DE L'ARBRE D'ACCESSIBILITÉ (F11.d).
 *
 * `display: none` et `visibility: hidden` masquent bien à l'œil — et retirent
 * l'élément de l'arbre d'accessibilité. Le bouton n'aurait alors PLUS AUCUN NOM
 * accessible : un lecteur d'écran annoncerait « bouton », sans dire lequel, et
 * le défaut serait invisible à la souris comme à l'œil. C'est très exactement
 * le mode de panne que F9.1.b décrit pour le focus clavier : invisible en
 * recette si personne ne teste autrement qu'à la souris.
 *
 * Le motif ci-dessous laisse l'élément RENDU — donc lu — tout en le réduisant à
 * un point invisible.
 *
 * ⚠️ POURQUOI CES `1px` NE VIENNENT PAS DE `front-variables.css`, ET POURQUOI
 * LES Y PRENDRE SERAIT UNE FAUTE. Ce ne sont pas des valeurs de CHARTE : ce
 * sont les constantes du MÉCANISME de masquage, dont la seule propriété utile
 * est d'être quasi nulles. Les faire venir de `--pst-epaisseur-bordure`, qui
 * vaut aussi `1px` aujourd'hui, coupleraient la géométrie du masquage à
 * l'épaisseur des bordures : le jour où la charte passerait les bordures à
 * `2px`, ce texte deviendrait un carré visible de deux pixels, sans que
 * personne n'ait touché à cette règle. La contrainte F9 vise ce qui doit suivre
 * la charte — pas ce qui doit lui rester étranger.
 *
 * ⚠️ ET C'EST `Test_Front_Css_Variables` QUI A TRANCHÉ OÙ PASSE CETTE FRONTIÈRE,
 * pas ce raisonnement. Une première version portait `margin: -1px`, héritée du
 * motif historique : le garde structurel l'a REFUSÉE — `margin` est une
 * propriété sous charte, `width` et `height` ne le sont pas. Plutôt que de
 * réclamer une exemption pour une valeur à unité (ce que ce garde exclut
 * explicitement), la marge a été RETIRÉE : sur un élément en `position:
 * absolute` déjà rogné par `clip-path`, elle ne produisait plus rien. Le
 * motif obtenu est celui que l'A11Y Project publie aujourd'hui — le garde a
 * donc corrigé une survivance, pas contraint une décision.
 */
.pst-front__masque-visuel {
	position: absolute;
	width: 1px;
	height: 1px;
	overflow: hidden;
	clip-path: inset( 50% );
	white-space: nowrap;
}

/* ------------------------------------------------------------------
 * F5.b — la feuille d'impression, détail de grille UNIQUEMENT.
 * ------------------------------------------------------------------ */

/**
 * ⚠️ POURQUOI CE BLOC EST STRUCTUREL, COMME F9, ET NE DÉPEND PAS DE LA CHARTE
 * (point tranché 2 du ticket F5). Le rôle d'une feuille d'impression est
 * presque entièrement structurel — masquer une action inutile sur papier,
 * empêcher qu'une ligne de tableau ne se coupe entre deux pages, adapter la
 * taille de police — aucun de ces choix ne dépend d'une teinte de charte.
 * Aucune valeur n'est écrite en dur ici : les deux tailles utilisées
 * (`--pst-taille-petite`) existent déjà dans `front-variables.css`, posées
 * avant même ce lot.
 *
 * ⚠️ POURQUOI `.pst-liste`/`.pst-front__conteneur` SONT PRÉFIXÉS
 * `.pst-detail`, ET POURQUOI `.pst-detail__visuel-telecharger` NE L'EST PAS —
 * DEUX RÈGLES OPPOSÉES, MESURÉES SÉPARÉMENT, PAS DEVINÉES. `.pst-liste` et
 * `.pst-front__conteneur` sont PARTAGÉS avec les listes publiques
 * (`[pst_grilles]`, `[pst_jock7]`) — le gabarit `Rendu_Liste` ne connaît ni
 * grille ni match (voir le POURQUOI de `.pst-liste th:first-child` plus
 * haut). Un sélecteur non préfixé imprimerait donc aussi les listes, hors du
 * périmètre de ce ticket. `.pst-detail__visuel-telecharger`, à l'inverse, ne
 * DOIT PAS être préfixé : mesuré sur le site réel (`curl` sur le rendu de
 * `[pst_grille]`, aucun `<a>` du plugin dans la page), ce lien n'appartient
 * PAS à la composition de `[pst_grille]` — `Visuels_Publics::bloc()`, que
 * `Shortcode_Detail` appelle, ne rend jamais `lien_telechargement()`. Il
 * n'existe que via le shortcode `[pst_visuel telechargeable="oui"]` autonome,
 * enveloppé dans `.pst-front` SEUL (POURQUOI de `Shortcode_Visuel` :
 * « `pst-front` SEULE, sans `pst-detail` »). Un préfixe `.pst-detail` aurait
 * donc rendu cette règle du CODE MORT sur la page qu'elle prétend cibler — la
 * classe elle-même ne peut de toute façon jamais apparaître ailleurs qu'à
 * cet endroit précis (son seul producteur dans tout le plugin), un préfixe
 * ne lui apporte donc aucune protection supplémentaire.
 *
 * ⚠️ POURQUOI AUCUNE RÈGLE NE CIBLE LE THÈME OU LA NAVIGATION DU SITE. « Ne
 * jamais dépendre d'un thème » (CLAUDE.md) vaut aussi à l'impression : ce
 * plugin ne connaît aucune classe de menu, d'en-tête ou de pied de page
 * appartenant au thème actif, et ne peut donc masquer que SON PROPRE
 * balisage.
 */
/* ==================================================================
 * T5.49 — PALETTE SOMBRE, ACCORDÉE À LA MAQUETTE DU DESIGNER
 * ==================================================================
 *
 * POURQUOI LES VALEURS VIENNENT DE LA MAQUETTE ET NON DU SITE EN LIGNE.
 * L'étape 1c a mesuré que le site trahit la charte sur presque tous les
 * points : son rouge (#e02b20) n'est aucun des cinq rouges de la charte, sa
 * police arabe est chargée puis jamais appelée, et ses règles typographiques
 * arabes sont l'inverse de ce que le designer a écrit. S'accorder au rendu
 * actuel aurait recopié ces défauts en croyant s'accorder à la charte.
 * Référence : docs/CHARTE-MAQUETTES-DESIGNER.md.
 *
 * ⚠️ CETTE PALETTE NE CHANGE QUE DES VARIABLES. Aucun sélecteur de mise en
 * page n'est redéfini ici — c'est ce qui permet à un intégrateur de composer
 * une TROISIÈME palette de la même façon, en surchargeant les mêmes noms
 * depuis le CSS additionnel de son thème, sans réécrire une règle ni recourir
 * à `!important`.
 *
 * Contraste de chaque couple, calculé sur ces valeurs et vérifié à la mesure :
 * texte courant 18,6:1 · texte atténué 9,5:1 · en-tête 13,5:1 · bouton 5,0:1 ·
 * état vide 9,2:1 · survol 16,4:1. Aucun sous 4,5:1.
 */
.pst-front--sombre {
	/* Socle — encres et neutres de la maquette. */
	--pst-couleur-fond: #030303;

	/* ⚠️ ÉCART ASSUMÉ À LA MAQUETTE (T5.58) — la bande était `#090909`
	   (`--ink-900`), le fond de plaque du designer. Écart mesuré contre le fond :
	   ratio 1,04:1, ΔY 0,0018, ΔL* 1,6 — les lignes paires ne se distinguaient
	   pas. `--ink-700` porte l'écart à 1,13:1, ΔY 0,0068, ΔL* 6,1, soit plus du
	   double de la référence claire (#ffffff/#f6f7f7, ΔL* 2,8).
	   `--ink-800` avait été écarté : un pas minimal aurait rendu les bandes « à
	   peine visibles » plutôt que visibles. Voir le POURQUOI complet de l'écart
	   sur `--pst-couleur-bordure` ci-dessous. */
	--pst-couleur-fond-attenue: #171514;
	--pst-couleur-texte: #f5f3ee;
	--pst-couleur-texte-attenue: #b4b0a8;
	/* ⚠️ ÉCART ASSUMÉ À LA MAQUETTE DU DESIGNER, ET IL FAUT SAVOIR POURQUOI
	   AVANT DE VOULOIR LE REFERMER (T5.58).

	   `rgba( 55, 52, 46, 0.7 )` n'était PAS une erreur de transcription : c'est
	   « le filet courant » du designer, sa valeur DOMINANTE — 19 occurrences
	   dans la maquette, sur les cartes, les plaques, les listes et les
	   vignettes (docs/CHARTE-MAQUETTES-DESIGNER.md, §6). Le plugin l'appliquait
	   fidèlement. Remettre cette valeur « pour se conformer à la charte » est
	   donc le geste qu'un lecteur futur fera spontanément — et c'est celui-ci
	   qui rouvrirait le défaut.

	   Composée sur `#030303`, elle donne `rgb(39,37,33)` : ratio 1,35:1,
	   ΔY 0,0180. La maquette tient EN MAQUETTE — regardée à plat, dans un
	   visionneur, sur un écran calibré. Elle ne tient pas sur un écran réel en
	   lumière ambiante, où le noir n'est jamais à zéro.

	   ⚠️ ET C'EST CE QUI A FAILLI FAIRE CONCLURE QUE LA PALETTE SOMBRE ALLAIT
	   BIEN. Le filet sombre mesurait 1,35:1 contre 1,37:1 pour le filet clair —
	   deux chiffres presque identiques, un rendu radicalement différent. Le
	   ratio WCAG est une DIVISION, donc invariant d'échelle : il dit « combien
	   de fois plus clair », jamais « à quelle distance ». Les deux couples
	   partagent leur ratio en étant séparés 15,7 fois moins en luminance
	   absolue (ΔY 0,283 contre 0,018). Et son terme `+ 0,05` modélise un voile
	   FIXE — reflets d'écran plus lumière ambiante — calibré pour un bureau
	   sombre. En faisant croître ce voile, le couple clair tient (1,37 → 1,25 à
	   0,40) et le couple sombre s'effondre (1,35 → 1,04) : il DISPARAÎT.

	   ⚠️ ΔL* NE RATTRAPE PAS L'ERREUR, IL LA REDOUBLE : il donne 14,1 en sombre
	   contre 12,2 en clair, annonçant le sombre comme le PLUS lisible. CIE L*
	   suppose un œil adapté à l'obscurité et un écran restituant les niveaux
	   près du noir. Aucune des trois mesures ne suffit seule ; c'est leur
	   DÉSACCORD qui a désigné le défaut.

	   `--metal-600` porte le filet à 4,43:1 sur le fond et 3,91:1 sur la bande
	   — le premier jeton de la charte à franchir 3:1, seuil du critère WCAG
	   1.4.11 « Non-text Contrast », celui qui s'applique aux filets et que les
	   384 couples TEXTE/fond de T5.49 et T5.57 n'ont jamais couvert.
	   `--metal-700` restait à 2,70:1, sous le seuil. */
	--pst-couleur-bordure: #78746c;

	/* POURQUOI l'or devient la couleur « primaire » : sur un fond noir, le vert
	   institutionnel #006030 tombe à 2,7:1 — il ne peut plus porter un titre.
	   La maquette confie ce rôle à son or (--gold-300), qui rend 14,0:1. */
	--pst-couleur-primaire: #f2d27a;
	--pst-couleur-primaire-claire: #fbf1d6;
	--pst-couleur-accent: #e4c568;
	--pst-couleur-annule: #d20a16;

	/* Rôles */
	--pst-couleur-fond-entete: #090909;
	--pst-couleur-texte-entete: #f2d27a;
	--pst-couleur-fond-survol: #171514;
	--pst-couleur-fond-survol-lien: rgba( 210, 10, 22, 0.11 );
	--pst-couleur-fond-champ: #030303;
	--pst-couleur-texte-champ: #f5f3ee;
	/* POURQUOI une bordure de champ PLUS CLAIRE que le filet courant : le champ
	   et le panneau de filtres partagent presque le même noir, et le filet à
	   rgba(55,52,46,.7) ne rend que 1,3:1 par-dessus — le champ deviendrait
	   invisible. #78746c rend 4,3:1, au-dessus du seuil de 3:1 des composants
	   d'interface (WCAG 1.4.11). */
	/* ⚠️ CE POURQUOI AVAIT DÉJÀ TOUT DIT, ET N'AVAIT CORRIGÉ QU'UNE VARIABLE.
	   Écrit à T5.49, il constate que le filet courant « ne rend que 1,3:1 » et
	   qu'à 3:1 il faut `#78746c` — puis n'applique la correction qu'au CHAMP,
	   laissant les filets, les cadres et les séparateurs à la valeur diagnostiquée
	   comme insuffisante. T5.58 étend la correction aux trois autres rôles. Le
	   diagnostic était juste et le correctif étroit : c'est la forme la plus
	   discrète du défaut, puisque le commentaire atteste qu'on avait compris. */
	--pst-couleur-bordure-champ: #78746c;
	/* ⚠️ RELEVÉE À `--metal-400` PARCE QUE T5.58 A DÉPLACÉ LA BASE. Elle valait
	   `#57534c` (2,70:1), ce qui était bien PLUS FORT que la base d'alors
	   (1,35:1). La base passant à 4,43:1, « forte » serait devenue plus FAIBLE
	   que la bordure ordinaire — une inversion créée par ce lot, pas héritée.
	   `--metal-400` rend 9,54:1 et rétablit l'ordre. Aucune règle du front ne la
	   consomme aujourd'hui : le correctif protège un usage futur, et l'écran
	   Présentation qui l'affiche. */
	--pst-couleur-bordure-forte: #b4b0a8;
	/* Le filet des tableaux et des séparations. Même valeur que la base, comme
	   en palette claire où `--attenuee` dérive de `--bordure` : c'est le rôle
	   qui porte le nom, pas une graduation. Voir le POURQUOI de l'écart sur
	   `--pst-couleur-bordure`. */
	--pst-couleur-bordure-attenuee: #78746c;
	/* POURQUOI le bouton reste PLEIN alors que la maquette le dessine en
	   contour rouge sur fond transparent : son bouton n'a pas de variable de
	   bordure propre dans ce lot, et en inventer une aurait ajouté une 17e
	   variable au périmètre arbitré. Le rouge plein rend 5,0:1 avec le blanc
	   cassé, le contour aurait rendu la même chose au texte — la différence est
	   esthétique, pas d'accessibilité. À rouvrir si la charte l'exige. */
	--pst-couleur-fond-bouton: #d20a16;
	--pst-couleur-texte-bouton: #f5f3ee;
	--pst-couleur-texte-vide: #b4b0a8;
	--pst-couleur-lien: #f2d27a;
	--pst-couleur-lien-survol: #fbf1d6;
	--pst-couleur-focus: #f2d27a;
}

/**
 * Le lavis de survol de ligne — idiome de la maquette (`.rows a:hover::before`,
 * un dégradé rouge depuis le bord d'attaque, jamais un aplat).
 *
 * ⚠️ POURQUOI IL N'EXISTE QU'EN PALETTE SOMBRE. En claire, `.pst-liste__ligne`
 * garde l'aplat `--pst-couleur-fond-survol` qu'elle avait avant ce ticket :
 * un dégradé y aurait été une modification d'apparence sur un thème clair, ce
 * que ce lot s'interdit.
 *
 * ⚠️ POURQUOI `to left` SANS ÉQUIVALENT LTR. `.pst-front` déclare
 * `direction: rtl` SANS CONDITION (D5, le front est en arabe) — mesuré : la
 * direction calculée reste `rtl` même sur une page `dir="ltr"`. Le bord
 * d'attaque est donc toujours le bord droit, et une règle `[dir="ltr"]`
 * symétrique serait du code mort qui se lirait comme une précaution.
 */
.pst-front--sombre .pst-liste__ligne:hover {
	background-image: linear-gradient( to left, var( --pst-couleur-fond-survol-lien ), transparent 55% );
}

/* ==================================================================
 * T5.49 — LE GABARIT NE COUPE PLUS LE TABLEAU DES 13 MATCHS
 * ==================================================================
 *
 * ⚠️ C'ÉTAIT UNE PERTE DE CONTENU, PAS UN INCONFORT. Mesuré à 380 px sur la
 * page réelle, avant ce correctif : le tableau des matchs fait 397 px dans un
 * `.pst-visuel` de 320 px qui porte `overflow-x: hidden` (scrollWidth 429,
 * clientWidth 320). Sur les 7 cellules d'une ligne, TROIS sont entièrement
 * hors écran — les deux buts et le résultat — et une quatrième coupée. Sans
 * barre de défilement, elles sont inatteignables : le visiteur ne peut pas
 * lire les scores. Identique en RTL et en LTR.
 *
 * POURQUOI LE CORRECTIF EST ICI ET PAS DANS LE GABARIT. `.pst-visuel` et sa
 * feuille appartiennent au gabarit de visuel, partagé avec la capture PNG :
 * y toucher changerait l'image produite. `.pst-gabarit` est l'enveloppe du
 * PLUGIN, et `front.css` n'est chargée que sur le front public — jamais sur la
 * page de capture, qui ne charge que la feuille du gabarit. Le contenu_html
 * n'est pas touché, et le PNG ne peut pas bouger.
 */
.pst-gabarit {
	overflow-x: auto;
}

/**
 * POURQUOI IL FAUT AUSSI LIBÉRER `.pst-visuel` : un conteneur ne défile que si
 * son contenu est plus large que lui. Tant que `.pst-visuel` se coupe
 * lui-même à 320 px, `.pst-gabarit` n'a rien à faire défiler et le correctif
 * ci-dessus serait sans effet — une règle posée, une mesure inchangée.
 *
 * ⚠️ POURQUOI TROIS CLASSES ET NON DEUX — MESURÉ, PAS ESTIMÉ. La première
 * écriture de cette règle était `.pst-gabarit > .pst-visuel`, et elle N'A RIEN
 * FAIT : `CSS.getMatchedStylesForNode` montre que le gabarit émet, dans son
 * `<style>` en ligne, `[data-pst-instance="…"] .pst-visuel--promo13 {
 * overflow: hidden }`. Un sélecteur d'attribut compte comme une classe : les
 * deux règles pèsent (0,0,2,0), l'égalité se tranche par l'ordre du document,
 * et ce `<style>` est ÉCRIT DANS l'enveloppe, donc après `front.css`.
 *
 * `.pst-front.pst-gabarit` porte les deux classes pour de bon — ce n'est pas
 * un artifice de spécificité mais la description exacte de l'élément — et pèse
 * (0,0,3,0). La mesure d'atteignabilité est passée de 3 cellules sur 7 à 7 sur
 * 7 à 380 px avec ce seul caractère de plus.
 *
 * ⚠️ CE QUI SE SERAIT PASSÉ SANS MESURER : la règle était présente, le
 * `overflow-x: auto` du parent aussi, et un contrôle qui aurait vérifié la
 * PRÉSENCE des deux règles aurait conclu que le défaut était corrigé. Il ne
 * l'était pas : trois colonnes — les deux buts et le résultat — restaient
 * inatteignables.
 */
.pst-front.pst-gabarit > .pst-visuel {
	overflow-x: visible;
}

/* ==================================================================
 * T5.49 — RESPONSIVE
 * ==================================================================
 *
 * ⚠️ LES PALIERS SONT ÉCRITS EN CLAIR, ET C'EST UNE LIMITE DU CSS, PAS UN
 * OUBLI. Une condition de `@media` n'accepte pas `var()` :
 * `@media (max-width: var(--x))` ne s'évalue jamais et la requête est ignorée
 * EN SILENCE. Les paliers ne sont donc pas retouchables par variable, et
 * `front-variables.css` le dit à l'endroit où on irait les chercher.
 *
 * 430 px et 768 px sont les deux premiers paliers de la charte du designer
 * (430 / 768 / 1024 / 1280 / 1920) — aucune valeur inventée. Les `.98`
 * évitent le recouvrement d'un pixel avec le palier supérieur.
 */

/**
 * Sous 768 px : le tableau défile, et il faut que cela SE VOIE.
 *
 * POURQUOI l'indication n'existe qu'ici : le défilement lui-même fonctionnait
 * déjà (mesuré — scrollWidth 520 / clientWidth 320, sans débordement de page).
 * Ce qui manquait n'était pas la mécanique, c'était le signal. Le poser à
 * toutes les largeurs aurait modifié l'apparence des pages de bureau sur un
 * thème clair, ce que ce lot s'interdit.
 *
 * Technique des ombres de défilement : les deux premières couches, en
 * `background-attachment: local`, suivent le contenu et MASQUENT les ombres
 * quand on est au bord ; les deux dernières, en `scroll`, restent fixes. Le
 * résultat est une ombre qui n'apparaît que du côté où il reste à défiler,
 * sans une ligne de JavaScript.
 */
@media ( max-width: 767.98px ) {

	.pst-front__conteneur {
		background-image:
			linear-gradient( to right, var( --pst-couleur-fond ), transparent ),
			linear-gradient( to left, var( --pst-couleur-fond ), transparent ),
			linear-gradient( to right, var( --pst-couleur-bordure ), transparent ),
			linear-gradient( to left, var( --pst-couleur-bordure ), transparent );
		background-position: left center, right center, left center, right center;
		background-repeat: no-repeat;
		background-size: 28px 100%, 28px 100%, 12px 100%, 12px 100%;
		background-attachment: local, local, scroll, scroll;
	}
}

/**
 * Sous 430 px : les contrôles passent en pleine largeur.
 *
 * POURQUOI la cible tactile est une variable et non `44px` en dur : c'est une
 * décision d'accessibilité, et un intégrateur doit pouvoir l'augmenter. La
 * réduire reste possible et reste son choix — mais elle est alors visible dans
 * son CSS, au lieu d'être enfouie dans le nôtre.
 *
 * Mesuré avant ce lot : 18 à 20 cibles sous 44 px sur les écrans de liste.
 */
@media ( max-width: 429.98px ) {

	.pst-filtres__champ {
		flex-basis: 100%;
	}

	.pst-filtres__valider {
		width: 100%;
	}

	/**
	 * Le lien qui couvre une ligne de tableau.
	 *
	 * POURQUOI SEULEMENT SOUS 430 px, alors que la maquette garantit 44 px sur
	 * TOUS ses liens à toute largeur : `.pst-liste__lien` est en `display:
	 * block` dans une cellule, et lui imposer 44 px double la hauteur de chaque
	 * ligne. Sur les treize matchs d'une grille, cela ferait passer le tableau
	 * de 286 px à 572 px — une modification d'apparence sur un thème clair, en
	 * bureau, que ce lot s'interdit. Au doigt, ce doublement est exactement ce
	 * qu'on veut ; à la souris, il n'apporte rien.
	 *
	 * Mesuré avant : 22,39 px de haut, soit la moitié de la cible.
	 */
	.pst-liste__lien {
		display: flex;
		align-items: center;
		min-height: var( --pst-hauteur-cible );
	}

	/**
	 * La liste de définitions passe en une colonne.
	 *
	 * POURQUOI : `--pst-largeur-libelle` vaut 12em, soit 192 px. Sur une
	 * fenêtre de 380 px dont le contenu occupe 320 px, il ne resterait que
	 * 128 px pour la valeur — une cagnotte à sept chiffres s'y replierait sur
	 * trois lignes. L'empilement suit l'idiome `dl.contact` de la maquette :
	 * libellé au-dessus, valeur en dessous, séparés par un filet bas.
	 */
	.pst-detail__liste {
		grid-template-columns: 1fr;
		gap: 0;
	}

	.pst-detail__liste dt {
		margin-top: var( --pst-espace-s );
	}

	/**
	 * ⚠️ CETTE RÈGLE NE TOUCHE PAS À L'ALIGNEMENT, ET C'EST DÉLIBÉRÉ (T5.61).
	 *
	 * Elle a porté `text-align: start` de T5.49 au 2026-09-08. C'était le
	 * renversement, dans un bloc média, de la décision de F12 — dont le
	 * POURQUOI complet vit sur la règle de base, à `.pst-detail__liste dd`, et
	 * explique précisément pourquoi `start` est le mauvais mot ici : `dir="auto"`
	 * fait retomber en `ltr` toute valeur sans caractère fortement directionnel
	 * — un nombre, une date rendue en `<span dir="rtl">` — et `start` y résout
	 * alors à GAUCHE.
	 *
	 * Mesuré à 380 px avant correction : **8 valeurs sur 9 décollées** du bord
	 * droit, `865` à 293 px vers la gauche. Seule `مختتمة`, arabe pur, tenait.
	 * Identique en `dir="ltr"` et en `dir="rtl"` : le sens de la page n'y entre
	 * pour rien, `.pst-front` déclarant `direction: rtl` sans condition (D5).
	 *
	 * ⚠️ ET RIEN NE REMPLACE LA DÉCLARATION RETIRÉE. Le passage en une colonne
	 * change la MISE EN PAGE, jamais le bord voulu : la règle de base pose déjà
	 * `right`, qui vaut pour les deux dispositions. Y réécrire `text-align:
	 * right` serait redondant — et rouvrirait la porte au prochain qui voudra
	 * « harmoniser » les deux valeurs en en changeant une seule.
	 */
	.pst-detail__liste dd {
		padding-bottom: var( --pst-espace-s );
		border-bottom: var( --pst-epaisseur-bordure ) solid var( --pst-couleur-bordure-attenuee );
	}
}

@media print {
	.pst-detail__visuel-telecharger {
		display: none;
	}

	/**
	 * `overflow-x: auto` (F1) et `min-width` (F9) existent pour FORCER le
	 * défilement horizontal d'un tableau trop large sur un écran étroit — deux
	 * mécanismes sans objet sur une page imprimée, qui ne défile jamais. Les
	 * laisser actifs couperait silencieusement le bord droit du tableau : la
	 * largeur minimale resterait plus grande que la zone imprimable, sans
	 * qu'aucun défilement ne permette de voir le reste.
	 */
	.pst-detail .pst-front__conteneur {
		overflow: visible;
	}

	.pst-detail .pst-liste {
		min-width: 0;
	}

	/**
	 * ⚠️ « ÉVITER QU'UN TABLEAU DE MATCHS NE SE COUPE AU MAUVAIS ENDROIT ENTRE
	 * DEUX PAGES » (feu vert F5.b). `break-inside: avoid` porte sur la LIGNE,
	 * jamais sur le tableau entier : un tableau de 13 matchs qui refuserait
	 * toute coupure obligerait le navigateur à soit l'écraser sur une seule
	 * page, soit ignorer la contrainte. Ce que ce ticket doit empêcher est plus
	 * précis — qu'une même ligne se retrouve à cheval sur deux pages, ses
	 * cellules de score séparées de son nom d'équipe.
	 */
	.pst-detail .pst-liste tr {
		break-inside: avoid;
	}

	/**
	 * Taille de police adaptée au papier (feu vert F5.b) : la taille
	 * secondaire déjà déclarée par F9, réutilisée plutôt qu'une valeur neuve.
	 */
	.pst-detail {
		font-size: var( --pst-taille-petite );
	}

	/**
	 * ⚠️ SANS CETTE RÈGLE, LA PRÉCÉDENTE N'ATTEINT PAS LE TABLEAU DES MATCHS —
	 * c'est-à-dire le seul élément que le critère 8 nomme. Mesuré le
	 * 2026-08-20 (Chrome/151.0.7922.169, `Emulation.setEmulatedMedia`) :
	 * `.pst-detail` passait bien à 14px, `.pst-detail__matchs` héritait 14px,
	 * et `.pst-liste` comme `.pst-liste__cellule` restaient à **16px**.
	 *
	 * POURQUOI, ET POURQUOI AUCUNE FEUILLE NE LE MONTRAIT. Le défaut n'est PAS
	 * un écrasement par le thème : `CSS.getMatchedStylesForNode` ne trouve
	 * AUCUNE déclaration de `font-size` sur la table ni sur ses cellules. La
	 * cause est un `.pst-front` IMBRIQUÉ — le conteneur du tableau porte
	 * `class="pst-front pst-front__conteneur"`, et `.pst-front` redéclare
	 * `font-size: var( --pst-taille-base )` pour lui-même (§F1). L'héritage
	 * repart donc de la taille de base au milieu du détail, qui porte pourtant
	 * lui aussi `.pst-front` (`class="pst-front pst-detail"`). Une chaîne qui
	 * se réinitialise en son milieu ne se voit sur aucune lecture de feuille de
	 * style : il faut mesurer chaque maillon.
	 *
	 * POURQUOI `inherit` PLUTÔT QUE DE RÉPÉTER `--pst-taille-petite`. Répéter la
	 * variable créerait deux endroits à tenir d'accord le jour où la taille
	 * d'impression change (règle 7). `inherit` dit ce qu'on veut réellement :
	 * à l'intérieur du détail, ne pas réinitialiser — laisser descendre ce que
	 * `.pst-detail` a fixé, quelle que soit sa valeur.
	 */
	.pst-detail .pst-front {
		font-size: inherit;
	}
}

/**
 * Les trois styles de liste offerts au réglage (F16.d).
 *
 * ⚠️ CES RÈGLES SONT DORMANTES, et c'est tout le dispositif. Elles sont écrites
 * ICI, par nous ; le réglage ne fait que poser l'une des trois classes sur le
 * tableau. Aucune déclaration CSS ne traverse jamais la saisie — F15 s'était
 * interdit la mise en page, et ce que cet interdit visait vraiment était la
 * saisie libre, pas la mise en page elle-même.
 *
 * ⚠️ LE QUATRIÈME STYLE, « simple », N'A AUCUNE RÈGLE : c'est le rendu
 * d'origine, obtenu par l'ABSENCE de classe. Lui en écrire une qui annulerait
 * les autres donnerait deux chemins vers le même rendu, dont un seul suivrait
 * une évolution du tableau de base.
 *
 * ⚠️ ET AUCUNE DE CES RÈGLES NE PORTE DE VALEUR LITTÉRALE : toutes lisent des
 * variables, comme le reste de la feuille — le test de F9 l'exige, et il
 * s'applique à ce qui est ajouté ici comme au reste.
 */

/* Bandes alternées : une ligne sur deux prend le fond atténué. */
.pst-liste--bandes tbody tr:nth-child(even) {
	background: var( --pst-couleur-fond-attenue );
}

/* Compact : le même tableau, resserré. Seul l'espacement change — les
   bordures et les couleurs restent celles du style d'origine. */
.pst-liste--compact th,
.pst-liste--compact .pst-liste__cellule {
	padding: var( --pst-espace-xs ) var( --pst-espace-s );
}

/* Sans bordures : les traits horizontaux disparaissent, l'en-tête garde son
   fond. POURQUOI l'en-tête n'est pas touché : sans trait ET sans fond, la
   ligne de titres cesse de se distinguer des données, et le tableau devient
   illisible — ce style allège, il ne supprime pas la structure. */
.pst-liste--sans-bordures th,
.pst-liste--sans-bordures .pst-liste__cellule {
	/* ⚠️ `border: 0` ET NON `border-bottom: 0` (T5.59) — c'est ici que le style
	   tient sa promesse. Ce sélecteur pèse DEUX classes, (0,0,2,0), quand celui
	   d'un thème qui habille les tableaux qu'il héberge en pèse une de moins :
	   `.entry-content tr td` de Divi vaut (0,0,1,2), et deux classes passent
	   devant une. Aucune spécificité n'a été montée pour cela — la règle
	   existait, elle ne parlait que du bas.

	   ⚠️ ET C'EST BIEN LE RACCOURCI QU'IL FAUT : `border-bottom: 0` seul
	   laissait le `border-top: 1px solid #eee` du thème, mesuré subsistant sous
	   Divi. Un style qui s'appelle « sans bordures » et en laisse une ment. */
	border: 0;
}

/* Échelle du gabarit de visuel rendu en HTML (T3.33, attribut `taille`).

   ⚠️ POURQUOI CES CLASSES EXISTENT PLUTÔT QU'UN `style="zoom:…"` SUR
   L'ENVELOPPE. Le front ne porte AUCUN style en ligne, et
   `Test_Charte_Appliquee::test_aucune_couleur_n_entre_dans_le_html_du_front`
   l'interdit sans exception. Cette garantie dépasse ce que son POURQUOI
   commente : une interdiction sans exception se vérifie d'un grep ; à une
   exception près, elle se relit. La liste reste vide.

   ⚠️ POURQUOI `zoom` ET NON `transform: scale()`. Mesuré sur la page front
   réelle, gabarit promo7 à 50 % : `transform` réduit le visuel à 540px mais
   RÉSERVE 1080px dans le flux — 540px de vide sous lui, que l'intégrateur ne
   peut pas combler. `zoom` réserve 540. Le trou serait une régression de la
   seule garantie que F17 donne : ne pas casser la page hôte.

   ⚠️ POURQUOI TROIS PALIERS, ET POURQUOI AUCUN AU-DESSUS DE 100 %.
   Mesuré sur un promo13 (13 lignes) dans une colonne de contenu de 760px :

     palier   largeur   hauteur réservée   police à l'écran
      25 %      195           299              5px  ← illisible
      50 %      390           571             10px
      75 %      585           856             15px
     100 %      760          1115             20px
     150 %      760          2095               —
     200 %      760          3639               —

   25 % est écarté : 5px de texte n'est pas une réduction, c'est un pavé gris.

   150 % et 200 % sont écartés pour une raison plus profonde : AU-DESSUS DE
   100 %, LA LARGEUR N'AUGMENTE PAS. Le gabarit est fluide depuis F17.2 ; le
   zoom réduit l'espace disponible en px CSS, et le contenu se replie en
   hauteur — ×1,9 puis ×3,3. Ce n'est pas « plus grand », c'est plus étroit et
   plus long. Et le résultat dépend entièrement de la largeur du conteneur :
   dans une fenêtre de 1400px sans colonne, ces mêmes paliers élargissent
   réellement. Un attribut dont l'effet dépend du thème n'est pas un attribut.

   Les trois paliers retenus sont nettement séparés (390 / 585 / 760) : aucun
   couple voisin n'est indiscernable. */
.pst-gabarit--50 {
	zoom: 0.5;
}

.pst-gabarit--75 {
	zoom: 0.75;
}