/* Statsmaker v2 — écran Glossaire. * * 🛑 POURQUOI CETTE FEUILLE A TRIPLÉ DE TAILLE. * * `v2/glossaire.html` était le SEUL des sept gabarits v2 à porter des styles en * ligne — 22 occurrences, contre 2 ou 3 pour chacun des six autres. Il est * aussi le seul des sept à avoir dérivé de la maquette, et ce n'est pas une * coïncidence : les deux écarts les plus visibles relevés par la partie 10 du * design étaient précisément deux valeurs restées en dur dans ce gabarit — * `top: 52px` sur la barre de catégories (recopié de la maquette, jamais * recalculé quand les contrôles sont passés à 44 px) et le `
` d'enrobage * qui avait sorti le bouton PDF de l'en-tête. * * Une valeur écrite dans un gabarit n'est révisée par personne le jour où le * système change autour d'elle. Tout est ici, et tout ce qui peut l'être passe * par un jeton. * * La maquette pose l'état des puces de catégorie en style en ligne calculé par * du JavaScript (`bg`, `color`, `border` recalculés à chaque rendu). Ici l'état * est porté par `aria-pressed` — donc annoncé aux technologies d'assistance — * et le style en découle. Une seule source de vérité, et l'information ne passe * plus par la seule couleur. */ /* ── Chapeau de page ────────────────────────────────────────────────────── */ .sm-gloss-titre { font-size: var(--fs-score); margin: 0 0 6px; } .sm-gloss-chapeau { color: var(--color-neutral-700); font-size: 15px; margin: 0 0 20px; text-wrap: pretty; } /* Bouton « Télécharger en PDF », rendu dans la FENTE D'ACTIONS de l'en-tête (`v2/partials/_actions_glossaire.html`) et non dans le corps — É-1. Valeurs de la maquette (`Glossary.dc.html:28-32`). `.btn` lui impose déjà `min-height: var(--sm-tap-min)`, ce qui ne coûte rien : la barre d'en-tête est haute de 44 px à cause de ses icônes. */ .sm-gloss-pdf { padding: 7px 15px; font-size: var(--fs-ui); } /* ── Champ de filtre ────────────────────────────────────────────────────── */ /* La bordure n'est PAS dans la maquette et elle reste : la pilule blanche sur fond `--color-bg` y a un contraste de limite de 1,06:1, sous le 3:1 de WCAG 1.4.11 (arbitrage F-4 / F-4bis, partie 7 §6.6). En revanche le `min-height: 36px` que portait l'input n'était prescrit nulle part — ni la maquette (aucune hauteur) ni la règle maison (44 px) : 21 px de haut gagnés pour rien. Il est remplacé par `.sm-touch-champ` (`sm-tokens.css`), qui donne la cible de 44 px sans changer un pixel visible. */ .sm-gloss-filtre { display: flex; align-items: center; gap: var(--sp-3); background: var(--color-surface); border: 1px solid var(--sm-border-field); border-radius: var(--r-pill); padding: 8px 16px; max-width: 360px; margin-bottom: 20px; } .sm-gloss-loupe { display: flex; color: var(--color-neutral-500); } .sm-gloss-q { border: none; background: none; font-size: var(--fs-body); width: 100%; color: inherit; font-family: inherit; } /* 🛑 DÉFAUT TROUVÉ EN SORTANT LES STYLES EN LIGNE, et c'est la démonstration de §3 : l'`outline: none` du champ vivait dans un `style=` du gabarit, donc HORS DE PORTÉE de `test_v2_css.PorteeEtSpecificiteTests`, qui balaye les feuilles. Il a rougi à la seconde où la déclaration est entrée dans un fichier CSS. Servi tel quel, le champ de filtre du glossaire n'avait AUCUN repère au clavier (WCAG 2.4.7) — troisième occurrence de ce motif sur ce chantier, et la première qu'aucun test ne pouvait voir. L'anneau est posé sur la PILULE, qui est le contrôle visible ; l'annuler sur le champ est alors borné à l'état de focus, pas au composant. `:focus-within` et non `:has(:focus-visible)` : l'audience est en 3G sur des navigateurs anciens, et `:focus-within` est disponible depuis 2018. Le prix est de montrer l'anneau aussi au clic — un anneau de trop vaut mieux qu'un anneau manquant. */ .sm-gloss-q:focus-visible { outline: none; } .sm-gloss-filtre:focus-within { outline: 2px solid var(--color-accent); outline-offset: 2px; } /* ── Barre de catégories (collante) ─────────────────────────────────────── */ /* ⚠️ `top: var(--sm-shell-h)` et JAMAIS un nombre. Ce `top` valait `52px`, recopié de la maquette dont l'en-tête fait 62 px ; le nôtre en fait 67 (63 sous 640 px) depuis que les contrôles sont passés à 44 px. La barre passait donc 15 px sous un en-tête translucide à `backdrop-filter: blur(10px)` : les puces apparaissaient rognées et floues par le haut dès qu'on défilait. Le jeton est CALCULÉ à partir du padding et de la hauteur de contrôle réels (`sm-tokens.css`) : il suit tout seul le prochain changement. */ /* ⚠️ Le `gap` de 7 px est PLUS PETIT que le débord de `.sm-touch` (8,5 px pour une puce de 27) : c'est le seul endroit du produit où R-T (b) n'est pas tenu, et c'est un arbitrage, pas un oubli — 1,5 px de recouvrement entre deux lignes de puces, mesurés, contre une densité que le client a choisie (le détail est plus bas, sur `.sm-gloss-chip`). Les deux variables ci-dessous déclarent le cas pour que la garde le VOIE au lieu de l'ignorer : `test_socle_cibles_tactiles.py` le porte dans ses arbitrages écrits. */ /* ── `--sm-collant-h` : cette barre EST le second étage collant du glossaire. * Déclarée sur `:root` — licite ici, cette feuille n'étant chargée que par * `v2/glossaire.html` — et DÉRIVÉE de ses trois composants réels : * 2 × 10 (padding) + 27 (hauteur visible d'une puce) + 1 (filet) = 48 px. * Elle sert le décalage d'ancre de `.sm-gloss-terme`, plus bas, qui annonçait * jusqu'ici une valeur « dérivée » de 53 px… écrite à la main, et fausse de * 5 px. `--sm-collant-top` en découle aussi, pour tout collant de 3ᵉ rang que * l'écran gagnerait. */ :root { --sm-gloss-barre-pad-y: 10px; --sm-gloss-chip-h: 27px; /* hauteur visible d'une `.sm-gloss-chip` */ --sm-gloss-barre-filet: 1px; --sm-collant-h: calc(var(--sm-gloss-barre-pad-y) * 2 + var(--sm-gloss-chip-h) + var(--sm-gloss-barre-filet)); } .sm-gloss-barre { --sm-touch-h: var(--sm-gloss-chip-h); --sm-touch-membre: sm-gloss-chip; /* le membre qui porte `.sm-touch` */ position: sticky; top: var(--sm-shell-h); z-index: 15; background: color-mix(in srgb, var(--color-bg) 92%, transparent); backdrop-filter: blur(8px); display: flex; gap: 7px; flex-wrap: wrap; align-items: center; padding: var(--sm-gloss-barre-pad-y) 0; margin-bottom: 10px; border-bottom: var(--sm-gloss-barre-filet) solid var(--color-divider); } .sm-gloss-compteur { margin-left: auto; font-size: var(--fs-cap); color: var(--color-neutral-700); } /* 🛑 D-B — SUR TÉLÉPHONE, LA BARRE SE REPLIE EN UN SEUL RANG DÉFILANT. * * Ce que la mesure montrait (rapport 14, §5.2), à hauteur d'écran réelle : * * 320×568 : en-tête 63 + barre 245 + onglets 66 = 374 figés → 194 px de lecture * 360×640 : en-tête 63 + barre 212 + onglets 66 = 341 figés → 299 px de lecture * * Soit 66 % et 53 % de l'écran gelés, pour UNE fiche de terme lisible à 320 px. * Le design pose en partie 3 §E.5 un engagement chiffré — « sur 360×640, après * l'en-tête, il reste environ 580 px » — que la fidélité à la maquette (neuf * puces sur six lignes) contredit frontalement. Le client a tranché pour §E.5, * sur téléphone SEULEMENT : au-dessus de 640 px, rien ne change ici. * * POURQUOI UN RANG DÉFILANT PLUTÔT QU'UNE BARRE DÉCOLLÉE. Les deux récupèrent * de la lecture, mais pas au même moment : * * - décoller la barre (`position: static`) ne rend RIEN au premier écran : * les 212 px sont toujours dans le flux, en haut du document. Le gain * n'arrive qu'après avoir fait défiler — c'est-à-dire après avoir traversé * la barre — et il se paie en perdant l'accès aux catégories ; * - un seul rang défilant fait tomber la barre de 212 à 48 px TOUT DE SUITE, * garde les neuf puces atteignables (au doigt par le défilement, au clavier * par la tabulation, qui fait défiler le conteneur toute seule puisque les * puces sont de vrais `