/* da-hud.animations.css — géométrie et mise en mouvement du thème DMPM HUD. Identique dans les deux dépôts. Aucune couleur en dur : tout passe par les jetons. TOUT est scopé par [data-da="dmpm-hud"], y compris les biseaux : sous une autre charte, aucune de ces classes ne produit le moindre effet — pas même un contexte de découpe. Voir README.md §Biseaux pour les rôles, les ombres et le mode clair. */ @keyframes hud-scan { 0% { transform: translateX(-30%); } 100% { transform: translateX(1300%); } } @keyframes hud-shimmer { 0% { transform: translateX(-120%); } 100% { transform: translateX(520%); } } @keyframes hud-ring { 0% { transform: scale(1); opacity: .55; } 70%, 100% { transform: scale(3.4); opacity: 0; } } @keyframes hud-blink { 0%, 45% { opacity: 1; } 55%, 100% { opacity: .15; } } @keyframes hud-flow { 0% { background-position: 0 0; } 100% { background-position: 24px 0; } } @keyframes hud-bracket { 0%, 100% { opacity: .35; } 50% { opacity: 1; } } @keyframes hud-breathe { 0%, 100% { box-shadow: inset 2px 0 0 var(--accent); } 50% { box-shadow: inset 2px 0 0 var(--accent-text), var(--glow, none); } } @keyframes hud-fill { from { transform: scaleX(0); } to { transform: scaleX(1); } } /* ══ BISEAUX ═══════════════════════════════════════════════════════════════════ Scopés par [data-da]. Un `clip-path`, même à 0px, crée un contexte de découpe qui rogne tout ce qui dépasse : appliquer ces classes hors du thème coupait les ombres débordantes de la charte DMPM (17 règles côté loxbackup). Elles ne mordent donc plus que sous ce thème. LA COUPE VAUT LE JETON SUR LES DEUX AXES — donc 45° partout, sur n'importe quel rapport de forme. Elle a été plafonnée par `min(jeton, 12%)` jusqu'au 2026-08-26 : ce filet de sécurité se résolvait PAR AXE, le pourcentage portant sur la largeur en x et sur la hauteur en y, et il aplatissait donc la diagonale dès que l'élément n'était pas carré. Mesuré dans l'application, sur 334 éléments biseautés rendus : 55 étaient à 45°, 279 s'en écartaient, l'écart médian valait 25,2° et le plus plat tombait à 4,6°. Les panneaux (--bevel-lg, format médian 768×158) coupaient à 45°, les champs et boutons (--bevel, format médian 186×35) à 19,2° : deux angles sur le MÊME écran, ce qui se lit comme un défaut de rendu et non comme un parti pris. CE QUE LE PLAFOND PROTÉGEAIT VRAIMENT — la question a été posée dans l'autre sens, et c'est la bonne : sans lui, y a-t-il des éléments où la coupe retirerait plus de 12 % d'un côté ? Oui, 279 sur 334. Mais 275 d'entre eux sont des champs et des boutons, que le tableau des rôles nomme explicitement sous --bevel : leur hauteur est simplement petite devant le jeton, ce n'est pas une violation. Les 4 autres en étaient une — une jauge de 8 px de haut, un point d'état de 8×8, deux pastilles rondes — et le plafond les rendait présentables au lieu de les signaler. Ils ont été retirés de la pose. Le plafond ne protégeait donc pas la géométrie : il masquait quatre erreurs de pose, et tordait les 330 autres éléments pour le faire. CE QUI LE REMPLACE EST UNE RÈGLE VÉRIFIABLE, pas un correctif silencieux : rien sous 24 px de haut n'est biseauté, et les familles exclues par le tableau des rôles — pastilles, badges, icônes, points d'état — ne le sont pas non plus. Côté Central, `scripts/themes.test.mjs` fait échouer la suite si une classe de biseau apparaît sur l'une d'elles. ⚠ CONSÉQUENCE À REGARDER, PAS À DÉDUIRE : la coupe d'un champ passe de 4,8 px à 12 px de haut, soit 41 % d'un champ de 29 px de haut. La géométrie est juste ; la VALEUR du jeton sur les petits éléments est une question de charte, et elle revient à Design. */ [data-da="dmpm-hud"] .da-bevel-sm { clip-path: polygon(0 0, calc(100% - var(--bevel-sm, 0px)) 0, 100% var(--bevel-sm, 0px), 100% 100%, var(--bevel-sm, 0px) 100%, 0 calc(100% - var(--bevel-sm, 0px))); } [data-da="dmpm-hud"] .da-bevel { clip-path: polygon(0 0, calc(100% - var(--bevel, 0px)) 0, 100% var(--bevel, 0px), 100% 100%, var(--bevel, 0px) 100%, 0 calc(100% - var(--bevel, 0px))); } [data-da="dmpm-hud"] .da-bevel-lg { clip-path: polygon(0 0, calc(100% - var(--bevel-lg, 0px)) 0, 100% var(--bevel-lg, 0px), 100% 100%, var(--bevel-lg, 0px) 100%, 0 calc(100% - var(--bevel-lg, 0px))); } [data-da="dmpm-hud"] .da-bevel-xl { clip-path: polygon(0 0, calc(100% - var(--bevel-xl, 0px)) 0, 100% var(--bevel-xl, 0px), 100% 100%, var(--bevel-xl, 0px) 100%, 0 calc(100% - var(--bevel-xl, 0px))); } /* ── Biseau, filet et ombre : la variante à face ─────────────────────────────── `filter` s'applique AVANT `clip-path` sur un même élément : une ombre portée y est dessinée puis rognée par la découpe. Les deux ne peuvent pas cohabiter sur le même élément. Le conteneur ne porte donc AUCUNE découpe — sa silhouette est faite de deux pseudo-éléments biseautés, et l'ombre est portée par celui du dessous. Conséquence recherchée, et non heureux hasard : le conteneur n'ayant pas de contexte de découpe, contour de focus, infobulle et menu déroulant débordent normalement. Toute évolution de ces règles doit préserver cette propriété. ⚠ AUCUN `filter` SUR L'ÉLÉMENT QUI PORTE DU CONTENU — c'est la règle qui a changé le 2026-08-26, et elle a été payée. Le filet était fait de quatre `drop-shadow()` décalés de 1,5 px, posés sur le conteneur. Sur un élément qui porte une face opaque, ces quatre passes détourent la face : c'est le dessin voulu. Sur une commande de formulaire, qui ne génère pas toujours ses pseudo-éléments, il n'y a AUCUNE face à détourer — les quatre passes s'appliquent alors à ce qui reste de visible, c'est-à-dire AU TEXTE, dont elles tracent quatre copies décalées. Mesuré en image sur un champ de 200×34 en mode clair : la surface encrée passait de 8 450 à 25 977 pixels, soit trois fois plus, et 27,3 % de la boîte changeait quand on retirait le filtre. Ce n'était pas un texte adouci, c'était un texte quadruplé. L'hypothèse d'origine — un filtre force le sous-arbre dans une couche composée et le texte y perd l'anticrénelage sous-pixel — n'a PAS été confirmée : le témoin non biseauté ne portait lui non plus aucune frange sous-pixel, donc ce rendu n'emploie pas cet anticrénelage du tout et l'instrument y était aveugle. On ne conclut pas d'une absence de signal : la cause retenue est celle qu'on a vue, le halo. DEUX COUCHES DÉCOUPÉES, ET AUCUN FILTRE SUR LE CONTENU : · `::after` porte le FILET — le polygone EXTÉRIEUR, peint en --bevel-edge, plus l'ombre portée. Un `filter` y est sans danger : ce pseudo-élément ne contient aucun texte, et l'ombre épouse enfin exactement la silhouette ; · `::before` porte la FACE — le MÊME polygone rentré de 1,5 px, peint en --face-bg. Ce qui dépasse du premier fait le trait. Le polygone rentré n'est pas le polygone extérieur mis à l'échelle : les quatre arêtes droites rentrent de 1,5 px, et la diagonale rentre de 1,5 px SELON SA NORMALE, ce qui déplace son intersection avec les bords de 1,5·(2 − √2) = 0,879 px. Mesurée depuis la boîte extérieure, la coupe du polygone rentré tombe donc à 1,5 px + jeton − 0,879 px, d'où le +0,621 px qu'on lit dans les règles ci-dessous. Un simple `inset()` ou un `scale()` donnerait un trait plus épais dans l'angle. POURQUOI ::after POUR LE FILET ET ::before POUR LA FACE, et pas l'inverse. Un élément n'a que deux pseudo-éléments, et `.da-bracket::after` en occupe un là où elle est posée. En cas de collision, l'élément perd le pseudo-élément le PLUS TARDIF : mieux vaut y perdre le filet — un trait de 1,5 px — que la face, c'est-à-dire le fond entier. L'arbitrage n'est pas laissé à la spécificité : les règles du filet, NON-PROPRIÉTAIRE de ::after, sont écrites dans :where() — spécificité (0,0,1) — donc .da-bracket::after gagne quel que soit le nombre de classes empilées en face (voir sa règle en bas de fichier, et README.md §Qui possède quel pseudo-élément). Central ne pose `.da-bracket` nulle part (vérifié le 2026-08-26). --face-bg N'EST PAS FACULTATIF sur tout élément dont le fond porte une information. Le repli --surface est juste pour une carte ou un panneau, destructeur sur un badge d'état : un badge « en erreur » repeint en --surface perd le lavis qui EST l'information. Voir le tableau des rôles dans README.md §Biseaux. ⚠ CES RÈGLES NE CONVIENNENT NI AUX COMMANDES DE FORMULAIRE NI AUX BOUTONS. Un `` ne génère NI ::before NI ::after — mesuré au pixel le 2026-08-26 : zéro pixel de face, alors que getComputedStyle répondait content: "" et un backgroundColor résolu, exactement comme pour un `
`. Un `