/* ===================================================
   FORME DES BOUTONS PAR DÉFAUT — SITE ENTIER
   =================================================== */

/* Retour Nicolas, 2026-07-22 : coins très légèrement arrondis sur tout
   bouton du site. La COULEUR (jaune -> accent) est gérée directement dans
   Apparence → Personnaliser → Couleurs ("Couleur des boutons", réglé par
   Nicolas le 2026-07-22) — pas ici, pour garder une seule source de
   vérité (un override CSS en plus du réglage aurait fait deux endroits à
   vérifier en cas de future modification). Seul l'arrondi, qui n'a pas
   d'équivalent dans Personnaliser, reste ici. */
.button,
.cart_totals .checkout-button,
.page-numbers:not(.current):not(.dots),
.post-page-numbers:not(.current):not(.dots),
.wp-block-button__link,
.wp-block-search .wp-block-search__button,
[type="button"],
[type="reset"],
[type="submit"],
button {
  border-radius: 6px;
}

/* 2026-10-27 — Exception : la flèche des sous-menus est un <button> dessiné
   en chevron (bordures droite+bas pivotées, voir css/style.css
   .toggle-sub-menus .button-toggle-sub-menu). Le `button` ci-dessus
   l'arrondissait aussi → chevron déformé. */
.toggle-sub-menus .button-toggle-sub-menu {
  border-radius: 0;
}

/* ===================================================
   HEADER STICKY SUR MOBILE AUSSI (pas juste desktop)
   =================================================== */

/* 2026-08-04 — ABANDON de position:sticky (mobile ET desktop, voir aussi plus
   bas dans ce fichier). Retour Nicolas : connecté, un espace de la hauteur
   du menu apparaissait AU-DESSUS du menu, sur Firefox seulement — confirmé
   par son propre test (retirer sticky faisait disparaître le problème).
   Piste explorée avant d'en arriver là : une valeur devinée pour la barre
   d'admin plutôt que mesurée (voir assets/js/sidebar.js) — corrigée mais
   insuffisante, le problème persistait. Plutôt que de continuer à chercher
   pourquoi sticky se comporte mal spécifiquement dans Firefox quand une
   variable CSS qu'il utilise change dynamiquement via JS après le premier
   rendu (--header-height/--real-admin-bar-height sont posées par JS), on
   revient à position:fixed (l'état d'avant le 2026-07-15) et on compense
   la réservation d'espace manuellement, comme avant — mais avec
   --header-height (mesurée) au lieu d'un chiffre deviné cette fois, ce qui
   n'était PAS le cas de l'ancien patch ci-dessous (juste "50px", jamais
   compatible avec la barre d'admin non plus). */
/* 2026-08-04, suite : le correctif ".wp-block-eedee-block-gutenslider" tenté
   ici a été RETIRÉ — Nicolas a trouvé un "espace énorme avant le slider" sur
   la page d'accueil CSE. Cause : .content-area (thème parent, présent sur
   TOUTES les pages, michelle/includes/Content/Container.php) a déjà
   padding-top:var(--content_padding) (~150px, confirmé par Nicolas). Sur les
   fiches/films, le mécanisme .alignfull:first-child (voir plus bas dans ce
   fichier) ANNULE ce padding avec une marge négative avant que je n'ajoute
   ma compensation — net correct. Sur la page d'accueil CSE, ce mécanisme
   scopé à .is-singular ne s'applique probablement PAS (page d'accueil, pas
   une page singulière) : rien n'annule les 150px, et ma marge s'y
   ADDITIONNAIT sans rien pour compenser. Retiré plutôt que deviné une
   troisième fois — aucune preuve confirmée que ce correctif réglait un vrai
   problème ailleurs (contrairement au bandeau des fiches, confirmé cassé
   puis corrigé), et preuve confirmée qu'il cassait CSE. Si le slider
   original ("home diffusion/formation", 2026-07) s'avère de nouveau caché
   sous le menu, le corriger avec une vraie mesure du contexte DE CETTE
   page précise plutôt qu'un sélecteur générique repris d'ailleurs. */

/* ===================================================
   ACCUEIL : PAS DE PADDING EN HAUT DE .content-area
   =================================================== */

/* ANNULÉ (2026-08-08, plus tard le même jour) : ce fix était une
   compensation pour un bug que j'avais moi-même créé dans la règle
   ".is-singular ... .alignfull:first-child" plus bas dans ce fichier (elle
   s'appliquait par erreur aussi à l'accueil, transformant l'annulation
   normale du padding de .content-area en addition). La vraie cause est
   corrigée à la source (exclusion "body:not(.home)" ajoutée à cette
   règle) — le mécanisme d'annulation du thème PARENT fonctionne à nouveau
   normalement sur l'accueil, comme sur toute page singulière. Garder ce
   padding-top:0 en plus aurait sur-corrigé (le slider aurait remonté sous
   le menu). Voir CHANGELOG. */

/* ===================================================
   MENU : PAS D'ESPACE À DROITE QUAND UN PANNEAU S'OUVRE
   =================================================== */

/* 2026-08-01 : "le menu ne doit pas avoir d'espace à droite quand le
   sidebar apparaît" — scrollbar-gutter:stable réservait en permanence
   l'espace de la barre de défilement pour éviter tout décalage à
   l'ouverture d'un panneau.

   RETIRÉ le 2026-08-08 : le thème PARENT a son propre système de
   compensation (variable --scrollbar_width, mesurée par SON JS, utilisée
   dans une dizaine de calculs `alignfull` à travers le thème — carrousel
   compris). scrollbar-gutter:stable perturbait cette mesure : "le slider
   est à droite complètement" (Nicolas) — un décalage touchant tous les
   blocs pleine largeur, pas seulement le carrousel. Devenu inutile de
   toute façon : le blocage du défilement se fait maintenant en JS pur
   (voir CHANGELOG, "Vraie cause du menu qui disparaît", même jour) sans
   jamais toucher à overflow — la barre de défilement ne disparaît donc
   plus jamais, plus besoin de lui réserver un espace fixe. */

/* ===================================================
   MARGE EN HAUT DU CONTENU — WIDE LAYOUT SEULEMENT
   =================================================== */

/* Retour Nicolas, 2026-07-24 : ma 1re version de ce fix visait #content
   SANS le scoper — ça poussait aussi la bannière plein écran de l'accueil
   (qui doit rester collée au header, par design) vers le bas. Corrigé :
   scopé à `.page-template-wide-layout` seulement (la page "Vidéos
   membres", qui n'a ni titre ni bannière pour créer un espacement
   naturel). L'accueil (template no-intro) n'est plus touché du tout par
   cette règle. Cause d'origine inchangée : css/style.css a
   `#content{margin:0}` avec `margin-top:50px` laissé en COMMENTAIRE — voir
   [[project_staging_css_enqueue]] pour pourquoi le fix va dans temp.css et
   pas dans style.css directement. */
.page-template-wide-layout #content {
  margin-top: 50px !important;
}

/* ===================================================
   MARGE GAUCHE/DROITE DU CONTENU — SITE ENTIER
   =================================================== */

/* Retour Nicolas, 2026-07-24 : le retrait de la colonne noire du sidebar
   (`#content{margin-left:0 !important}` un peu plus bas, demandé le
   2026-07-14 — DÉPLOYÉ SEULEMENT SUR STAGING, jamais poussé en prod à
   cause de bugs de marge similaires à ceux d'aujourd'hui) a bien retiré
   l'espace réservé pour cette colonne, comme voulu — mais rien n'a repris
   le relais avec une marge à lui, donc le contenu colle maintenant à
   l'écran. Principe de Nicolas : `#content` peut légitimement rester à 0
   (l'espace du sidebar ne doit pas revenir), mais un niveau plus interne
   doit porter une vraie marge. `.content-area` (entre #content et #main)
   est le bon endroit : présente sur TOUTE page, et le thème parent ne lui
   donne déjà QUE du padding vertical par défaut (jamais horizontal) — donc
   visiblement la couche prévue pour ça à l'origine.

   Valeur choisie (24px) : plus légère que l'ancien 50px "réservé sidebar"
   de la prod — vu que ce n'est plus pour compenser une colonne, juste pour
   ne pas coller à l'écran. Facile à ajuster si besoin.

   Pages single-film/single-projection/single-evenements/single-fiche déjà
   exclues automatiquement : `.single-film .content-area{padding:0}` (etc.,
   css/style.css ~ligne 599) a 2 classes = plus spécifique que la règle
   ci-dessous, continue de gagner sans rien ajouter de plus. Ces templates
   gèrent déjà leur propre largeur directement sur #content. */
.content-area {
  padding-left: 24px;
  padding-right: 24px;
}

/* ===================================================
   WIDE LAYOUT (/templates/wide-layout.php)
   Corrections mobile - n'affecte aucun autre template
   =================================================== */

/* Retour Nicolas, 2026-07-22 : espace vide en haut de la page
   videos-membres (template wide-layout, pas de titre affiché) — le thème
   parent applique .content-area{padding:var(--content_padding) 0} par
   défaut sur TOUTES les pages (michelle/assets/css/content.css), pensé
   pour laisser la place au titre. Sans titre sur ce template, ça laisse
   juste un espace vide. Toutes largeurs (pas seulement mobile) — retire
   seulement le padding du HAUT, garde celui du bas. */
.page-template-wide-layout .content-area {
  padding-top: 0;
}

/* Marge minimale gauche/droite, TOUTES largeurs (pas juste mobile).
   Nicolas, 2026-08-18 : constat en direct sur diffusion.funambulesmedias.org
   — deux pages avec EXACTEMENT le même gabarit (wide-layout) donnent des
   résultats opposés : l'une a un texte correctement centré (~610px, grâce
   au système natif de largeur de bloc Gutenberg), l'autre un texte collé
   aux DEUX bords (0px de marge, cinema-et-resistances) — le gabarit seul ne
   garantit rien sur bureau, seule la version mobile (ci-dessous) avait un
   filet de sécurité. Un simple padding, pas une largeur imposée (pas de
   max-width/margin:auto) : si la page a déjà une marge correcte via
   Gutenberg, ça n'ajoute presque rien ; sinon, ça garantit un minimum.

   IMPORTANT : ciblé sur les enfants DIRECTS de .entry-content, PAS
   .entry-content elle-même, et exclut .alignfull/.alignwide — vérifié que
   les 2 autres pages utilisant ce gabarit (tournee-voir-juger-agir, EN et
   FR) ont une bannière .wp-block-cover.alignfull mesurée pleine largeur
   (1905px = viewport). Un padding sur .entry-content directement (avec
   box-sizing:border-box) aurait rétréci CETTE bannière de ~32px de chaque
   côté (elle hérite de la largeur du parent via `width:inherit` dans la
   règle .alignfull existante) — régression évitée en excluant ces blocs. */
.page-template-wide-layout .entry-content > *:not(.alignfull):not(.alignwide) {
  padding-left: max(2rem, calc((100% - 1600px) / 2));
  padding-right: max(2rem, calc((100% - 1600px) / 2));
  box-sizing: border-box;
}

@media (max-width: 880px) {

  /* Cache la bannière full-screen du haut */
  .page-template-wide-layout .wp-block-cover.alignfull {
    display: none;
  }

  /* Classe utilitaire pour cacher n'importe quel bloc sur mobile via Gutenberg */
  .page-template-wide-layout .hide-on-mobile {
    display: none !important;
  }

  /* Remettre les marges latérales du contenu sur mobile */
  .page-template-wide-layout .entry-content {
    margin-top: 0 !important;
    padding-top: 0 !important;
    padding-left: 16px !important;
    padding-right: 16px !important;
  }

  /* Annule le padding-top du header sticky quand le cover bannière est caché sur mobile.
     Sur les autres pages ce padding est absorbé par le cover. Ici il crée un espace vide. */
  .page-template-wide-layout #page,
  .page-template-wide-layout #content {
    padding-top: 0 !important;
    margin-top: 0 !important;
  }

  /* Cache uniquement la galerie grid de logos partenaires sur mobile.
     Le carrousel (.kb-gallery-type-carousel) reste visible.
     Lié au template wide-layout uniquement — n'affecte pas les autres pages. */
  .page-template-wide-layout .kb-gallery-type-grid:not(.kb-gallery-funambules-portfolio) {
    display: none;
  }

  /* Accordion Kadence - lisibilité mobile */
  .page-template-wide-layout .kt-blocks-accordion-header {
    font-size: 15px;
    line-height: 1.4;
    padding: 12px 10px;
    white-space: normal;
    word-break: break-word;
  }

  .page-template-wide-layout .kt-accordion-panel-inner {
    padding: 12px 10px;
    font-size: 15px;
    line-height: 1.6;
  }

  .page-template-wide-layout .kt-accordion-panel-inner ul {
    padding-left: 16px;
  }

  .page-template-wide-layout .kt-accordion-panel-inner li {
    margin-bottom: 10px;
    word-break: break-word;
  }

  .page-template-wide-layout .kt-accordion-panel-inner p {
    margin-bottom: 8px;
  }
}

/* ===================================================================
   MENU DESKTOP EN HAMBURGER FLOTTANT — remis à l'essentiel (2026-07-14) :
   retirer la colonne noire de 50px + reprendre l'espace qu'elle réservait.
   RIEN D'AUTRE — les tentatives de "plein écran partout" (images,
   .entry-content, .site-main, .content-area) sont abandonnées : ce n'était
   pas le but demandé, et ça cassait des pages sans rapport avec la colonne
   (catalogue CAC, pages standards). Retour de Nicolas, 2026-07-14 : "il
   fallait juste retirer la colonne... tout pourrait être comme avant avec
   simplement l'espace sidebar retiré".
   POUR REVENIR EN ARRIÈRE : supprimer tout ce bloc jusqu'à "FIN".
   =================================================================== */
@media screen and (min-width: 880px) {
  /* #masthead{position:fixed} (css/style.css:1449-1455) sort le menu du flux normal —
     rien ne réserve sa hauteur, donc le contenu qui suit (ex. le bandeau .wp-block-cover
     des fiches/films) commence à y:0 et se fait recouvrir. J'avais compensé avec un
     margin-top manuel sur le bandeau, mais ça créait un espace en trop (le menu fixed
     ne bouge pas avec le flux, donc rajouter de la marge ailleurs ne fait que décaler
     le contenu sans réserver correctement l'espace du menu lui-même). position:sticky
     règle ça à la racine : le menu garde sa place normale dans la page (repousse
     automatiquement tout ce qui suit, comme un volet figé Excel), et une fois qu'on
     défile jusqu'à lui, il se colle en haut de l'écran au lieu de continuer à défiler —
     plus besoin de marge compensatoire nulle part. Retour de Nicolas, 2026-07-15. */
  /* ERREUR CORRIGÉE (2026-07-15), round 2 : le thème PARENT gère déjà la barre d'admin
     correctement — ".admin-bar .site-header{top:var(--wp-admin--admin-bar--height)}"
     (global.css) — #masthead a aussi la classe .site-header. Mon "#masthead{top:0}"
     (sélecteur ID, plus spécifique que ".admin-bar .site-header" à deux classes) gagnait
     TOUJOURS, même connecté, et écrasait ce mécanisme déjà correct — d'où "tu as ajouté
     un espace quand je ne suis pas connecté" (en fait l'inverse aussi : ça cassait le
     décalage attendu quand on EST connecté). Fix : ne plus fixer "top" via l'ID — utiliser
     .site-header (même sélecteur que le thème, même spécificité, mais chargé après donc
     gagne pour le cas par défaut) pour laisser la règle plus spécifique du thème
     (.admin-bar .site-header) reprendre la main automatiquement quand la barre est là.
     Retour de Nicolas : "le thème doit déjà avoir prévu un truc pour la barre WordPress
     non ?" — oui, il ne fallait juste pas l'écraser. */
  /* 2026-08-04 : plus de position:sticky ici (voir le commentaire complet en
     haut de ce fichier). #masthead reste donc en position:fixed, sa règle de
     base dans css/style.css — rien à répéter ici.

     ESSAI RATÉ, retiré : margin-top sur #content (l'ancêtre). Résultat, capture
     à l'appui : un écart visible entre le menu et le bandeau .wp-block-cover
     des fiches. Cause : le thème PARENT tire déjà ce bandeau vers le haut
     (".alignfull:first-child{margin-top:var(--content_padding_negative)}"
     ≈ -90px, michelle/assets/scss/global/wp/_alignment.scss:119-122) — mon
     margin-top sur #content s'ADDITIONNAIT à cette marge négative existante
     au lieu de la remplacer, créant l'écart en trop. C'est très probablement
     l'erreur exacte qu'avait faite le patch pré-07-15 ("créait un espace en
     trop") en visant le bandeau MAIS en plus d'un mécanisme déjà là, pas
     forcément juste à cause d'un chiffre deviné.

     Fix correct : REMPLACER cette marge négative sur le SÉLECTEUR EXACT du
     thème parent (mêmes classes, donc même spécificité — !important pour
     trancher), au lieu d'ajouter une marge ailleurs qui s'additionne. */
  /* 2026-08-08 : ajout de "body:not(.home)" — cette règle remplace la marge
     négative du thème PARENT (--content_padding_negative, qui ANNULE le
     padding-top de .content-area par design, pour compenser le fait que
     #masthead est position:fixed sur les fiches/films et ne réserve pas
     d'espace). Sans l'exclusion, elle s'appliquait AUSSI à l'accueil (page
     statique donc .is-singular ET .home en même temps) : au lieu d'annuler
     le padding-top de .content-area comme prévu par le thème, elle s'y
     ADDITIONNAIT (marge positive au lieu de négative), recréant l'espace
     avant le slider — le vrai bug derrière le fix "body.home .content-area
     {padding-top:0}" plus haut, qui n'était qu'une compensation pour CE
     problème-ci. Exclure .home restaure le mécanisme d'annulation d'origine
     du thème sur l'accueil, sans toucher aux fiches/films (qui n'ont jamais
     la classe .home). */
  body:not(.home) .is-singular:not([class*="-content-only"]):not(.has-primary-title) .entry-content-singular > .alignfull:first-child,
  .error-404-content > .alignfull:first-child {
    margin-top: var(--header-height, 50px) !important;
  }
  .site-header {
    top: 0;
  }
  /* Filet de sécurité pour le cas connecté : DEUX sélecteurs redondants
     poussent le menu (body.admin-bar ET body.current-user-has-role-
     administrator), comme pour mobile plus bas dans ce fichier — avant,
     desktop ne comptait que sur la règle du thème PARENT
     (".admin-bar .site-header", global.css), sans filet si cette classe
     précise n'est pas celle réellement posée sur <body> dans ce contexte
     (retour Nicolas, capture à l'appui, 2026-08-04). */
  body.admin-bar .site-header,
  body.current-user-has-role-administrator .site-header {
    /* --real-admin-bar-height : mesurée en direct (assets/js/sidebar.js), pas
       devinée par palier — voir son commentaire pour le contexte complet
       (2026-08-04). Repli sur la valeur devinée si le JS n'a pas encore tourné. */
    top: var(--real-admin-bar-height, var(--wp-admin--admin-bar--height));
  }
  /* ABANDON du positionnement calculé de #sidebar-mini (position:fixed, top/left/
     transform devinés au pixel — bouton mal placé, "bougeait" selon la connexion
     admin, et redevenait mal placé au moindre changement de hauteur de header).
     Retour de Nicolas, 2026-07-15 : "ça pourrait pas juste être toujours le
     sidebar mini [mobile] ?" — en effet #sidebar-mobile est un élément DANS le
     flux normal de .site-branding (flex, aligné avec le logo automatiquement par
     le navigateur), pas besoin de deviner sa position. On l'utilise maintenant
     à TOUTES les largeurs d'écran, et #sidebar-mini (fixed, calculé) reste
     toujours caché. Élimine aussi le saut visuel qui se produisait au
     redimensionnement, exactement à la bascule 880px. */
  #sidebar-mini {
    display: none !important;
  }
  /* ABANDON du calcul left/transform : la vraie cause de l'espacement imprévisible
     bouton↔logo est .site-branding{justify-content:space-between} (thème parent), qui
     redistribue l'espace ÉLASTIQUEMENT entre les 3 enfants (bouton/logo/texte) selon la
     largeur réelle de .site-branding (elle-même variable selon l'écran, cf. max-width
     50%/38.2% plus haut) — pas une marge fixe qu'on peut viser avec un calcul unique.
     Nicolas, 2026-07-15 : "je ne vois pas comment rapprocher le logo" (en cherchant
     dans l'inspecteur) confirme qu'il n'y a pas de marge simple à ajuster.
     Fix : on sort du space-between pour CE cas précis. flex-start empile bouton+logo+
     texte au début (fini l'élasticité) ; margin-left:auto sur le texte reproduit la
     seule partie du comportement d'origine qu'on veut garder (le texte poussé à
     l'extrême droite). Le bouton et le logo sont maintenant adjacents de façon stable,
     donc une marge fixe sur le bouton (= le même padding-left que le conteneur, pour
     un espace identique des deux côtés) donne enfin un résultat prévisible. */
  .site-branding {
    justify-content: flex-start;
  }
  .site-branding-text {
    margin-left: auto;
  }
  #sidebar-mobile {
    display: block !important;
    /* 15px des DEUX côtés (retour Nicolas, 2026-07-15 : "c'est proche, mets 15px chaque
       côté"). Le bouton démarre naturellement à padding-left du conteneur
       (.site-header-section{padding-left:3.42105rem} ≈ 54.7px) — margin-left négatif
       pour ramener le bord gauche à 15px du bord de l'écran, margin-right:15px pour un
       espace identique jusqu'au logo. */
    margin-left: calc(15px - 3.42105rem);
    margin-right: 15px;
    /* "Le burger est trop bas" (Nicolas, 2026-07-15) : .site-branding{align-items:
       flex-end} aligne tous ses enfants sur le BAS de la rangée. Le logo (haut,
       jusqu'à 2.5em) et le bouton (court) partagent donc le même bord du bas, mais le
       petit bouton paraît "trop bas" par rapport au centre visuel du logo. On centre
       CE bouton précisément (sans toucher à l'alignement du logo/texte, réglé ailleurs
       via align-items sur le conteneur). */
    align-self: center;
  }
  /* !important nécessaire : une règle plus spécifique existe dans
     css/style.css (".single-film #content,.single-projection #content,
     .single-evenements #content{width:calc(100vw - 50px)}", ~ligne 597-603)
     qui gagnait sinon sur les pages film. */
  #content {
    margin-left: 0 !important;
    width: 100% !important;
  }
  /* .content-area{max-width:var(--layout_width_content)=1400px;margin:0 auto}
     (thème parent, content.css) plafonne et centre le contenu. Débridé
     complètement le 2026-07-15 ("je veux que le site entier... soit pleine
     largeur"), mais ça allait trop loin — Nicolas, 2026-07-24 : "content-
     area, c'est correct à 1400px... au pire on mettra 1600" — replafonné,
     SAUF `.page-template-wide-layout` qui doit rester pleine largeur (c'est
     son rôle). .site-main (largeur du TEXTE, --layout_width_entry_content)
     n'est toujours pas touché ici, comme demandé le 07-15.

     CORRIGÉ (2026-07-25, audit pré-mise en ligne) : la 1re version ne
     excluait que .page-template-wide-layout — mais les fiches film/
     projection/événement (.single-film/.single-projection/
     .single-evenements/.single-fiche) ont LEUR PROPRE mécanisme de pleine
     largeur (#content{width:calc(100vw - 50px)}, css/style.css ~ligne
     599-604, pour la mise en page "cinéma" avec titres verticaux) — le
     plafond de 1400px sur .content-area serait venu le contredire par en
     dessous (contenu recentré à 1400px À L'INTÉRIEUR d'un #content déjà
     presque pleine largeur). Ajoutées à l'exclusion.

     CATALOGUE EXCLU AUSSI (2026-07-25, retour Nicolas : "ça marchait bien,
     je dirais de ne pas y toucher" + "s'assurer que le système fait en
     sorte qu'on n'y touche plus") : le catalogue (CAC ET CSE, même
     composant) n'a PAS de gabarit/classe dédié détectable au niveau du
     <body> — juste une page normale avec le shortcode [funambules_grille].
     Plutôt que de cibler un ID/slug de page (fragile : différent par
     domaine, casserait si le catalogue est un jour déplacé vers une
     nouvelle page), on cible directement le VRAI composant du catalogue
     via :has() — `.grid-filters` (voir
     funambules-grille-v2/views/FiltersView.php) est le conteneur du
     catalogue peu importe la page/le domaine qui l'affiche. Résultat :
     n'importe quelle page contenant le catalogue reste pleine largeur
     automatiquement, même une future page qu'on ne connaît pas encore —
     pas besoin d'ajouter une exclusion à la main à chaque fois. */
  body:not(.page-template-wide-layout):not(.single-film):not(.single-projection):not(.single-evenements):not(.single-fiche) .content-area:not(:has(.grid-filters)) {
    max-width: 1400px;
    margin-left: auto;
    margin-right: auto;
  }
  .page-template-wide-layout .content-area {
    max-width: none;
    margin-left: 0;
    margin-right: 0;
  }
  .site-footer-section {
    padding-left: 0 !important;
  }
  .subsite-footer-section {
    margin-left: 0 !important;
  }
}
/* === FIN MENU DESKTOP === */

/* ===================================================================
   ABANDON de la règle générale "tout contenu non-alignfull est recentré" :
   elle touchait aussi des blocs qui DOIVENT rester pleine largeur (ex. un
   bloc synopsis à fond noir, sans classe .alignfull mais quand même conçu
   pleine largeur — "il ne faut pas de marge pour ce contenu... y a une
   marche sur le contenu à l'intérieur des blocs"). Retour au principe
   d'origine de Nicolas : tout le site pleine largeur PAR DÉFAUT — on cible
   maintenant SEULEMENT le cas précis signalé (galerie "Nouveautés"), rien
   d'autre, pour ne plus jouer au chat et à la souris avec chaque section. */
@media screen and (min-width: 880px) {
  .entry-content > .wp-block-gallery {
    max-width: var(--layout_width_content, 1400px);
    margin-left: auto;
    margin-right: auto;
  }
}

/* ===================================================================
   DRAWER (#sidebar-full) : ERREUR CORRIGÉE (round 2). Le fix précédent ne
   décalait le panneau QUE de la hauteur de la barre d'admin (32px), sans
   tenir compte de la hauteur du MENU lui-même (#masthead, 50px) — donc le
   panneau chevauchait/cachait le menu sur certaines pages (grille-
   horaire), tout en restant "trop bas" sur d'autres (fiche), selon que la
   classe .admin-bar était présente ou non à ce moment précis. Nicolas,
   2026-07-15 : "le drawer cache le menu sur grille-horaire... trop bas
   sur la fiche... je le veux directement sous le menu."
   Fix complet : le panneau commence maintenant TOUJOURS juste sous le
   menu (50px), que la barre d'admin soit là ou non — + sa hauteur en
   moins pour ne jamais déborder du bas de l'écran.

   NETTOYÉ (2026-07-25, retour Nicolas : "pourquoi la connexion WP ne peut
   pas juste être toujours prise en compte ?") : les 2 règles précédentes
   (#sidebar-full seul, puis body.admin-bar #sidebar-full en plus)
   faisaient la même chose avec ou sans duplication inutile — la variable
   --wp-admin--admin-bar--height vaut déjà 0 automatiquement quand la
   barre n'existe pas (repli explicite à 0px sinon). Fusionné en UNE seule
   règle, plus besoin de sélecteur body.admin-bar séparé : mathématiquement
   identique (50px+0=50px quand pas connecté), donc ce nettoyage seul ne
   changeait rien au calcul.

   CORRIGÉ POUR DE VRAI (2026-07-25, retour Nicolas : "ce n'est pas en px
   qu'il faut réfléchir") : le "50px" restait un chiffre deviné, pas
   mesuré — remplacé par --header-height, la VRAIE hauteur rendue de
   #masthead, mesurée par JS (assets/js/sidebar.js, chargé site-wide) et
   posée sur <html>. Le panneau se cale automatiquement même si le menu
   change de hauteur pour une raison qu'on n'a pas prévue (barre de
   notification, retour à la ligne...). Même variable que .cac-drawer
   (funambules-grille-cac-v2/style.css) — une seule vraie source, plus de
   nombres dupliqués à recalculer à chaque nouveau composant.

   SIMPLIFIÉ ENCORE (2026-07-25, retour Nicolas : "il faut que ce soit
   prévu toujours pareil [connecté ou non], ça me semble la base.") :
   --header-height mesure maintenant directement où le menu se termine à
   l'écran (bottom, pas juste sa propre hauteur) — la barre d'admin est
   DÉJÀ incluse dans cette mesure (elle pousse #masthead vers le bas, ce
   qui déplace directement son bord du bas). Plus besoin d'additionner
   --wp-admin--admin-bar--height séparément ici : un seul chiffre,
   connecté ou non, pareil partout. */
#sidebar-full {
  top: var(--header-height, 50px);
  height: calc(100% - var(--header-height, 50px));
}

/* Icône du menu "Mon compte" (retour Nicolas, 2026-07-21) : récupérée
   depuis le dev (alacarte.funambules.wpdev0.koumbit.net), où elle
   fonctionne déjà. Nécessite assets/img/user.svg — absent de staging pour
   l'instant, à téléverser en plus de ce fichier. */
.menu-primary .profile-username > a {
  background-image: url(/wp-content/themes/michelle-child/assets/img/user.svg);
  background-position: 0 0;
  background-repeat: no-repeat;
  background-size: 40px;
  padding-left: 2.10526rem;
}

/* Ligne "invité·e·s" dans la boîte SÉANCE (single-projection.php) : icône +
   texte en noir comme le reste du texte de la boîte, pas la couleur d'accent
   bleu-gris par défaut de .fnmb-drawer__icon/.fnmb-drawer__value (pensée
   pour LE VRAI tiroir latéral, funambules-seances-sidebar — pas touché ici,
   scopé à .projection_grille_item seulement). Nicolas, 2026-08-19. */
.projection_grille_item .fnmb-drawer__icon,
.projection_grille_item .fnmb-drawer__value {
  color: #000;
}

/* .fnmb-drawer__row a une bordure du bas comme séparateur entre plusieurs
   lignes empilées (le vrai tiroir latéral) — retirée normalement sur la
   DERNIÈRE ligne via :last-child. Ici, la ligne invité n'est jamais le
   dernier enfant de .projection_grille_item (le <h5> "En collaboration
   avec" et le logo du partenaire la suivent) : :last-child ne s'applique
   donc jamais, la bordure reste — "ligne blanche" signalée par Nicolas
   avant les partenaires, 2026-08-19. Retirée explicitement ici. */
.projection_grille_item .fnmb-drawer__row {
  border-bottom: none;
}

/* Le fond beige (body.custom-background) coupe sec directement sur le pied
   de page — .content-area/l'article de single-projection.php finissent à
   padding-bottom:0, aucun espace avant le footer. Nicolas, 2026-08-19 :
   "ça coupe un peu sec". Un peu de respiration en bas, scopé à cette page
   seulement. */
.single-projection .content-area {
  padding-bottom: 4rem;
}

/* Carte film (article.film, fond beige) dans "FILMS PRÉSENTÉS" de
   single-projection.php : coupe juste après les thématiques (.tags),
   aucun espace en bas — même symptôme que le correctif équivalent dans
   funambules-films-selection (grille séparée), mais ICI c'est la grille
   NATIVE de single-projection.php (#posts.posts-list-film dans
   .films_presentes), pas ma sélection. Scopé à .single-projection
   seulement — .tags/article.film restent un style partagé (catalogue,
   archives...), ne pas y toucher globalement. Nicolas, 2026-08-19 :
   "c'est trop court" (2e signalement, mauvaise grille identifiée la 1re
   fois).

   CORRIGÉ : le padding sur chaque <article> n'avait "aucun impact" —
   Isotope (js/drawer.js? non — la petite boucle JS de single-projection.php,
   layoutMode:'fitRows') positionne chaque carte en position:absolute et
   calcule la hauteur de #posts par JavaScript ; le padding d'un enfant
   absolument positionné ne change rien à l'espace visible. Nicolas a
   confirmé dans l'inspecteur que le padding sur #posts LUI-MÊME fonctionne
   (testé à 20px) — déplacé ici. */
.single-projection .films_presentes #posts.posts-list-film {
  padding-bottom: 20px !important;
}

/* ===================================================================
   ÉQUIPE (/a-propos/equipe/) : GRILLE LIMITÉE À ~2 COLONNES
   =================================================================== */

/* Nicolas, 2026-09-16 : "les photos sont sur 2 colonnes" — persistait même
   après correction du min-width:35% qui fuyait depuis .equipe-slider (voir
   CHANGELOG). Vraie cause, différente : .site-main a son propre plafond
   `.site-main{max-width:var(--layout_width_entry_content)}` (thème PARENT,
   michelle/assets/css/content.css) — pensé pour la largeur de LECTURE d'un
   article (~950px), pas pour une grille de photos. .content-area (le niveau
   juste au-dessus) est déjà débridé à 1400px pour cette page (règle
   "MENU DESKTOP EN HAMBURGER FLOTTANT" plus haut dans ce fichier), mais
   .site-main (à l'intérieur) reste plafonné à ~950px — ce qui limite la
   grille à environ 2 photos par rangée peu importe la largeur d'écran
   (confirmé : le conteneur ne s'élargit pas du tout entre 1280px et 1600px
   de fenêtre, contrairement à un simple manque de colonnes responsive).
   Même principe que l'exclusion du catalogue plus haut (:has(.grid-filters)) :
   cibler le VRAI composant plutôt qu'un gabarit/ID de page, pour que ça
   reste correct si la page est un jour déplacée ou dupliquée. */
.site-main:has(.equipe) {
  max-width: 1400px;
}