/** * Composants dont l'ordre visuel est décidé par la MISE EN PAGE, jamais par * l'algorithme bidirectionnel Unicode (F1, étape 3). * * Extrait de promo13.css / promo7.css / jock7.css, où ces trois règles * étaient écrites à l'identique — jock7.css renvoyait déjà explicitement au * POURQUOI de promo13.css, la duplication était donc reconnue par le code * lui-même. Le front public a besoin du même motif : sans cette extraction, il * en existerait une quatrième copie, et la première correction appliquée à * l'une des quatre ferait diverger les autres en silence. * * ⚠️ Ce fichier ne contient QUE ce qui est commun aux trois domaines. Tout ce * qui varie (couleurs, tailles, marges) reste dans la feuille du domaine : * ce qu'on partage ici, on s'engage à le vouloir identique partout. * * ------------------------------------------------------------------ * POURQUOI display: inline-flex + direction: rtl, pour les trois * ------------------------------------------------------------------ * * Le principe est le même dans les trois cas : chaque composant est un * isolé, et c'est le modèle de boîte flex sous direction: rtl qui place le * premier enfant DOM à DROITE. L'ordre visuel ne dépend donc jamais d'UAX#9 * appliqué à une chaîne de texte. * * .pst-score — score combiné but 1 / but 2 (correctif bidi du 2026-08-07). * UAX#9 traite « 1-2 » comme un nombre unique, donc toujours affiché de gauche * à droite. Chaque but est un span purement numérique posé par * Moteur_Substitution::formater_score_combine() ; sous direction: rtl, le * premier enfant (but 1) se place à droite, aligné sur la colonne équipe 1. * * .pst-date — composants de date/heure (T6.7, correctif recette réelle). * Voir le POURQUOI complet dans Date_Publique::formater(). * Chaque composant (.pst-date__jour-nom, __jour-chiffre, __mois, __annee, * __heure) est purement arabe ou purement numérique, jamais mixte. * * .pst-supp — donnée supplémentaire configurable (T1.8). Même principe, avec * une DIFFÉRENCE à ne pas gommer : les composants des deux autres sont * garantis homogènes, alors que le libellé ET la valeur sont ici du texte * LIBRE, potentiellement mixte. C'est pourquoi * Moteur_Substitution::formater_donnee_supplementaire() pose en plus un * dir="auto" sur ces deux spans : chacun fixe sa direction de base sur son * propre contenu et s'isole de ses voisins. Retirer ces attributs ferait * réapparaître le bug sur une valeur du type « Ooredoo 2026 ». */ .pst-score, .pst-date, .pst-supp { display: inline-flex; align-items: baseline; direction: rtl; } /** * POURQUOI les écarts sont ici et non dans les feuilles de domaine : ils * étaient déjà IDENTIQUES dans les trois (2px pour le score, 6px pour les * deux autres). Les laisser derrière aurait gardé la duplication en n'en * déplaçant que la moitié — et la moitié restante est justement celle qu'on * aurait oublié de tenir à jour. */ .pst-score { gap: 2px; } .pst-date, .pst-supp { gap: 6px; } /** * ------------------------------------------------------------------ * Match non joué — l'onde manuscrite qui le barre (T5.74) * ------------------------------------------------------------------ * * ⚠️ UNE SEULE ONDE, ICI, POUR LE FRONT ET POUR LES VISUELS. Elle remplace un * trait droit qui existait en TROIS exemplaires — front.css, promo13.css, * promo7.css — avec déjà une divergence : 2px sur le front contre 3px sur les * visuels, que rien ne motivait nulle part. C'était une divergence en attente, * du genre que le POURQUOI en tête de ce fichier existe pour empêcher. * * Cette feuille est chargée des DEUX côtés, et c'est ce qui autorise le * partage : `Assets_Front::enregistrer()` en fait une dépendance de front.css, * et `Admin_Visuel::rendre_page_visuel()` une dépendance de la feuille de * domaine — donc de tout gabarit, y compris ceux déjà créés en base. * * ⚠️ LE TRACÉ EST UN MASQUE, PAS UNE IMAGE DE FOND, ET LA DIFFÉRENCE EST TOUT * L'ENJEU DE LA COULEUR. Un SVG en `data:` URI employé comme IMAGE est un * document séparé : ni `var()` ni `currentColor` n'y pénètrent, et sa couleur * serait donc CUITE dans l'URI — il en faudrait une copie par thème, et les * copies divergeraient. En masque, le SVG ne porte que la FORME ; la couleur * vient de `background-color`, donc de la palette. * * ⚠️ POURQUOI UN REPLI DE COULEUR PLUTÔT QUE DEUX RÈGLES : le front définit * `--pst-couleur-annule` (clair #d0021b, sombre #d20a16), la page de capture * d'un visuel NE CHARGE PAS `front-variables.css` — sa chaîne est fonts.css → * ce fichier → feuille de domaine. La variable y est donc absente, et le repli * rend exactement la valeur que les deux feuilles de visuel écrivaient en dur. * Un seul `background-color` sert ainsi trois couleurs. * * ⚠️ `top: calc( 50% - 4px )` ET NON `transform: translateY( -50% )`, alors que * la seconde forme est l'idiome habituel. front.css interdit explicitement * `transform` autour de ce pseudo-élément — une transformation crée un BLOC * CONTENEUR, et le trait s'y recalerait (mesuré à F3 : couverture 1,000 → 1,172, * le trait déborde du tableau). L'interdit vise les ANCÊTRES et non le * pseudo-élément lui-même, donc un `transform` serait ici sans danger — mais il * se lirait comme une infraction, et le `calc()` obtient le même centrage sans * ouvrir la question. * * ⚠️ LE TRAIT DROIT RESTE LA BASE, ET CE N'EST PAS UNE PRÉCAUTION DÉCORATIVE : * sans lui, un moteur ignorant `mask-image` peindrait le `background-color` SUR * TOUTE LA BANDE — une barre pleine de 8px, bien pire que le trait de 2px * d'aujourd'hui. Le repli dégrade donc vers l'état connu, jamais vers pire. * Même construction que le `@supports not (writing-mode: sideways-lr)` des * feuilles de visuel. * * ⚠️ R18 EST RESPECTÉE PAR CONSTRUCTION : un `data:` URI n'est pas une * ressource externe — rien ne part sur le réseau, et * `Template_Service::est_url_externe()` l'exempte nommément. Le `contenu_html` * des gabarits n'est pas touché : l'onde vit dans la feuille, comme le trait. * * MESURES (2026-09-13, site Docker de test, sonde servie en HTTP MÊME ORIGINE — * en file:// une capture perd des ressources qui fonctionnent en production) : * * • Survie à `domToPng` : 3 bandes attendues, 3 obtenues sous Chrome * 152.0.7977.84 comme sous Firefox 155.0. Éprouvé par mutation — URI rendue * invalide, les deux moteurs tombent à 2 bandes et nomment la manquante. * * • Part de l'ENCRE DU TEXTE recouverte, comparée au trait droit qu'elle * remplace — mesurée position par position contre un rendu sans barré, jamais * par une quantité de rouge (une onde plus large en mettrait davantage sans * rien cacher de plus si elle tombait entre les glyphes) : * * front 1280px Chrome 0,68 % → 0,51 % Firefox 1,10 % → 1,19 % * front 380px Chrome 1,53 % → 0,90 % Firefox 1,95 % → 1,30 % * visuel 1080px Chrome 0,29 % → 0,08 % Firefox 0,23 % → 0,06 % * * L'onde masque donc MOINS que le trait partout sauf Firefox à 1280px, où * c'est une égalité. Le trait est une barre pleine ; l'onde est un tracé de * 2px qui ne touche les glyphes qu'aux croisements. * * ⚠️ CE QUI N'A PAS ÉTÉ MESURÉ : WebKit — Safari, et donc tout navigateur sur * iOS — aucun moteur WebKit n'étant disponible sur la machine de développement. * Même borne que celle déjà écrite dans front.css pour le trait droit. Les * préfixes `-webkit-mask-*` sont posés pour cette borne précise, jamais parce * qu'un moteur mesuré en aurait besoin : Chrome les ignore depuis la 120 et * Firefox depuis la 53. */ .pst-liste__ligne--annule, .pst-visuel__match--annule { position: relative; } .pst-liste__ligne--annule::after, .pst-visuel__match--annule::after { content: ""; position: absolute; inset-inline: 0; top: calc( 50% - 1px ); height: 2px; background-color: var( --pst-couleur-annule, #d0021b ); pointer-events: none; } @supports ( mask-image: url( "" ) ) or ( -webkit-mask-image: url( "" ) ) { .pst-liste__ligne--annule::after, .pst-visuel__match--annule::after { top: calc( 50% - 4px ); height: 8px; mask-image: url( "data:image/svg+xml;utf8," ); mask-repeat: repeat-x; mask-size: 24px 8px; -webkit-mask-image: url( "data:image/svg+xml;utf8," ); -webkit-mask-repeat: repeat-x; -webkit-mask-size: 24px 8px; } }