/* =====================================================================
   LES PAGES À LECTEUR — le titre passe SOUS le lecteur
   jerevise.fr · chantier LECTEUR-HAUTEUR, 23/10/2026
   =====================================================================

   CE FICHIER EST LE SEUL ENDROIT où vit l'allure des pages dont le
   contenu principal est un lecteur : exercice en ligne, vidéo, vidéo
   d'écriture. Décision de Gaetan du 23/10/2026 : on fait comme YouTube,
   le titre va sous le lecteur, en taille normale et en gras, et il
   reste le `h1` unique de la page.

   IL NE TOUCHE JAMAIS À `.sound-lesson-title` SEULE. Cette classe est
   aussi celle du grand titre des LEÇONS, qui ne change pas : tout passe
   par `.jr-titre-sous`, qui n'est posée que sur les pages à lecteur.

   ATTENTION — TROIS NOMBRES D'ICI COMPENSENT DES VALEURS QUI VIVENT
   DANS LE LECTEUR (`lecteur-reglages.css`). Le jour où la version 2 du
   lecteur sera reportée dans `lecteur.html` — tâche LH-3 de
   `~/projet/chantiers/TODO-jerevise.md` —, ILS SE REVÉRIFIENT :
   si la marge basse du lecteur, sa marge latérale ou l'ombre de son
   cadre changent, la page se décale sans que rien ne le signale. C'est
   une dépendance à sens unique, et elle n'est visible que d'ici.
   Le relevé se refait avec `mesurer-bords.py` et `mesurer-ecarts.py`
   du chantier.
   ===================================================================== */

:root {
  /* LA REMONTÉE DU TITRE SOUS LE CADRE.
     Mesuré le 23/10/2026, Chrome et WebKit, 1280x800 et 390x844 : il y
     avait 68 px entre le bas VISIBLE du cadre et le haut du titre.
       40 px  la marge basse du <body> du LECTEUR, dans l'iframe
       28 px  la marge basse de `.jr-exo-cadre` (integration.css)
     On en reprend 54 et on laisse 14, parce que l'OMBRE du cadre
     (`0 8px 16px -4px`) porte au plus bas à -4 + 8 + 8 = 12 px. À 14 px
     le titre est juste dessous, et l'ombre n'est ni rognée ni traversée. */
  --jr-titre-remonte: 54px;

  /* LE BLANC SOUS LE LIEN DE RETOUR : deux lignes au moins.
     3,25 rem = 52 px, soit deux lignes du texte courant (interligne 1,6)
     et deux lignes et demie du paragraphe qui suit (interligne 1,3).
     EN `rem` ET PAS EN `em` : le `em` se compterait sur le corps du
     LIEN, qui est à 15 px — mesuré, il rendait 49 px au lieu de 52.
     ET EN CSS, JAMAIS EN PARAGRAPHES VIDES : un `<p>&nbsp;</p>`
     compterait comme un paragraphe pour Ezoic et déplacerait ses
     bannières. */
  --jr-retour-blanc: 3.25rem;

  /* L'ALIGNEMENT DU TEXTE SUR LE BORD VISIBLE DU CADRE.
     Le <body> du lecteur réserve `max(16px, env(safe-area-inset-left))`
     À L'INTÉRIEUR de l'iframe — c'est ce qui tient l'ombre latérale. Le
     texte, lui, est aligné sur l'iframe : il commençait donc 16 px à
     gauche du cadre. On élargit le conteneur d'autant, côté page. */
  --jr-lecteur-bord: 16px;

  /* LA REMONTÉE DU LECTEUR SOUS L'EN-TÊTE DU SITE.
     Mesuré le 23/10/2026 sur la page servie, EN VISITEUR ANONYME : il
     n'y a que **17 px** entre le bas de l'en-tête et le haut visible du
     cadre sur un PC, et **11 px** sur un téléphone. Pas une ligne de
     texte (26 px) : l'en-tête du site est `position: fixed`, et le
     `padding-top` de `.site-inner` (50 px bureau, 80 px téléphone) est
     tout ce qui empêche le contenu de passer dessous.
     On prend donc tout ce qu'il y a, moins les 8 px qu'on s'est promis
     de laisser voir entre l'en-tête et le cadre.
     ATTENTION — ce que montre l'APERÇU d'un brouillon est plus grand :
     WordPress y ajoute sa barre d'administration de 32 px, que le
     visiteur ne voit jamais.
     `0px` ici rend exactement l'état d'avant. */
  --jr-lecteur-haut: 9px;

  /* LA MARGE HAUTE QUE POSE `integration.css` SUR LE CONTENEUR, nommée
     pour que le calcul ci-dessous se relise sans aller la chercher. */
  --jr-exo-marge-haut: 20px;
}

/* SOUS 768 px, LA COLONNE DU SITE N'A PLUS QUE 15 px DE MARGE (c'est
   `style.min.css` qui le pose, pas nous) : en reprendre 16 ferait
   déborder la page d'un pixel de chaque côté, donc une barre de
   défilement horizontale. On reprend tout ce qu'il y a, pas plus.
   Il reste 1 px d'écart sur téléphone, contre 16 avant. */
@media (max-width: 768px) {
  :root {
    --jr-lecteur-bord: 15px;
    /* 11 px disponibles sur telephone, moins les 8 px promis.
       11 EST LE PIRE DES DEUX MOTEURS : Chrome mesure 11 px quand
       WebKit en mesure 17, l'en-tete n'y ayant pas tout a fait la meme
       hauteur. Prendre 17 ferait sauter le garde-fou chez l'un des
       deux. */
    --jr-lecteur-haut: 3px;
  }
}

/* ============ LA TABLETTE EN PORTRAIT, 600 a 768 px ============
   Ajoute le 24/10/2026 (LECTEUR-HAUTEUR-02), sur signalement de Gaetan :
   sur un iPad en portrait il n'y avait AUCUN blanc entre la bande de
   l'en-tete et le haut visible du cadre, la ou le garde-fou du chantier
   en promet 8.

   LA CAUSE EST UNE VALEUR MESUREE AILLEURS. Le bloc `max-width: 768px`
   ci-dessus REPREND 3 px sur la marge haute du conteneur — valeur
   mesuree sur le TELEPHONE (§ 37 du journal), ou l'en-tete n'a pas la
   meme hauteur. A cette largeur-ci il n'y avait que 3 px de disponible :
   on prenait tout, et il ne restait rien.

   Releve a 600, 640, 700, 767 et 768 px de large, les deux moteurs : la
   bande est UNIFORME — Chrome 125/125, ecart 0 ; WebKit 119/125,
   ecart 6. Une seule valeur suffit donc pour toute la bande.

   ON NE REPREND PAS, ON REND 5 px : la marge haute passe de 17 a 25 px,
   et l'ecart de 0 a 8 sur Chrome, de 6 a 14 sur WebKit. C'est le seul
   endroit du fichier ou cette variable est NEGATIVE, et c'est bien ce
   qu'elle veut dire — elle compte ce qu'on reprend sur la marge.

   `min-width: 600px` N'EST PAS DECORATIF : le bloc est ainsi DISJOINT
   de `max-width: 599px` ci-dessous, donc aucun des deux ne peut mordre
   sur l'autre. Et il vient APRES le bloc `max-width: 768px` dont il
   corrige la valeur : a specificite egale sur `:root`, c'est le dernier
   qui l'emporte.

   AU-DESSUS DE 768 px, RIEN NE CHANGE — verifie a 769, 820x1180 et
   1280x800 : l'iPad a 820 garde ses 5 px, qui sont l'etat valide du
   § 53 et ne sont pas l'objet de cette correction. */
@media (min-width: 600px) and (max-width: 768px) {
  :root { --jr-lecteur-haut: -5px; }
}

/* ============ LE TÉLÉPHONE, ET LUI SEUL ============
   Ajouté le 23/10/2026. Sur un iPhone il restait de la place au-dessus
   du lecteur, et elle n'était pas où la mesure l'avait d'abord
   cherchée : elle était DANS la boîte de l'en-tête, sous le champ de
   recherche — 8 px de fond peint qui ne tenaient rien.

   CES 8 px NE SONT PLUS RETIRÉS ICI. Décision de Gaetan du 23/10/2026 :
   c'est un défaut de l'EN-TÊTE, pas des pages à lecteur, et il se
   corrige pour TOUT LE SITE dans `css/entete.css`, enfilée partout.
   L'en-tête a ainsi la même hauteur sur toutes les pages.

   CE QUI RESTE ICI est la seule chose qui regarde le lecteur : il
   remonte de **11 px** sur smartphone — les 3 px pris sur la marge du
   conteneur, plus les 8 px que l'en-tête vient de rendre. Les deux
   corrections s'additionnent exactement comme avant, et le résultat sur
   la page d'exercice est identique au brouillon validé : bande de
   l'en-tête à 109, haut visible du cadre à 117, 8 px de blanc entre les
   deux.

   SOUS 600 px, ET PAS SOUS 768 : le seuil exclut les tablettes en
   portrait. Vérifié que l'iPad reste STRICTEMENT inchangé, 768x1024 et
   820x1180, sur les deux moteurs.

   ET CE QUE MONTRE L'APERÇU D'UN BROUILLON N'EST PAS À PRENDRE :
   WordPress y ajoute sa barre d'administration, **46 px sur téléphone**
   (32 px au-dessus de 782 px) — mesuré. Un visiteur ne l'a jamais.

   ATTENTION À L'ORDRE : ce bloc vient APRÈS `max-width: 768px`. Les
   deux visent `:root`, donc à spécificité égale c'est le dernier qui
   l'emporte ; écrit avant, le `3px` du bloc 768 annulerait le `11px`. */
@media (max-width: 599px) {
  :root { --jr-lecteur-haut: 11px; }
}

/* LE TITRE. `.entry-content h1.jr-titre-sous` vaut (0,2,1) et bat donc
   `.entry-content h1` du thème, qui vaut (0,1,1) et impose 48 px
   centrés.

   SAUF POUR LA MARGE HAUTE, ET IL A FALLU LA VRAIE PAGE POUR LE VOIR.
   `style.min.css` porte, plus bas que sa propre règle de titre :

       .entry-content h1 { margin-top: 1.2em !important; }

   Un `!important` ne se bat pas à la spécificité : il se bat à
   l'importance. Mesuré le 23/10/2026 sur la page servie, la remontée du
   titre **ne s'appliquait pas** — l'écart sous le cadre restait à 68 px
   au lieu de 14. La maquette ne pouvait pas le voir : elle avait copié
   la règle de titre du thème, pas celle-là.

   D'où un `!important` ici, et sur cette seule déclaration. Il répond à
   un `!important` existant ; il n'en ajoute pas un de confort. */
.entry-content h1.jr-titre-sous {
  font-size: 1rem;
  line-height: 1.35;
  font-weight: 700;
  text-align: left;
  color: var(--text-gray, #333);
  margin: 0 0 6px 0;
  margin-top: calc(-1 * var(--jr-titre-remonte, 0px)) !important;
}

/* LE LIEN DE RETOUR, sous le titre, et le blanc qui le sépare du texte.
   Il est en `<div>` et non en `<p>` : ainsi il n'est plus le PREMIER
   PARAGRAPHE de la page, et l'emplacement Ezoic qui porte ce nom ne
   peut plus venir s'y glisser. */
.entry-content .jr-retour {
  margin: 0 0 var(--jr-retour-blanc, 14px) 0;
  font-size: 15px;
}

/* LE CONTENEUR DU LECTEUR, élargi de la marge que le lecteur réserve au
   dedans. L'ombre est dans l'iframe, qui ne fait que s'élargir : elle
   n'est pas rognée. Et le cadre ne touche jamais le bord de l'écran,
   même quand l'iframe l'atteint — les 16 px du lecteur sont dedans. */
/* `.entry-content .jr-exo-cadre` ET PAS `.jr-exo-cadre` SEUL — defaut
   trouve par le controle complet du 24/10/2026, sur la page PUBLIQUE.
   `integration.css` est posee par le champ `_genesis_scripts` de la
   page, qui sort APRES les feuilles enfilees par `wp_enqueue_style` :

     21167  style.min.css
     36512  page-lecteur.css
     37015  integration.css      <- apres la notre

   Elle porte `.jr-exo-cadre { margin: 20px auto 28px auto }`, de MEME
   specificite que la notre (0,1,0) : a egalite, c'est la derniere qui
   gagne, et son raccourci `margin` ecrasait nos deux longhands. Ni la
   remontee ni l'alignement ne s'appliquaient — 276 contre 260 au bord
   gauche, et 17 px sous l'en-tete au lieu de 8.

   ON REPOND PAR LA SPECIFICITE, PAS PAR L'ORDRE : (0,2,0) l'emporte ou
   que soit la feuille. Un `!important` aurait marche aussi ; il aurait
   surtout rendu la regle inarretable par la suivante.

   LA MAQUETTE NE POUVAIT PAS LE VOIR : elle ecrivait les deux regles
   dans la meme feuille, dans l'ordre qui l'arrangeait. */
.entry-content .jr-exo-cadre,
.entry-content .video-container.jr-lecteur,
.entry-content .quiz-container.jr-lecteur {
  margin-inline: calc(-1 * var(--jr-lecteur-bord));
  /* ET LA REMONTEE. On REDUIT la marge haute, on ne la rend pas
     negative : tant qu'il reste du vide a prendre, on prend du vide
     reel plutot que de faire chevaucher quoi que ce soit. */
  margin-top: calc(var(--jr-exo-marge-haut, 20px) - var(--jr-lecteur-haut, 0px));
}