/* * Arc_Prod File Role: Frontend asset (CSS/JS) for tenant/admin UI behavior or styling. * File: public_html/assets/xhelpers/css/components.css */ /** * XHelpers - COUCHE COMPOSANTS CANONIQUE * * A QUOI SERT CE FICHIER * Un seul endroit ou lire l'apparence d'un composant transverse, et un seul endroit * ou la corriger. Avant ce fichier, il fallait simuler la cascade a travers QUATRE * passes de base.css, situees lignes 68, 994, 1082 et 1267, pour savoir de quoi une * cellule de tableau avait l'air. * * CE QUE CE FICHIER EST, ET CE QU'IL N'EST PAS * Il porte les regles qui etaient dans base.css, DEPLACEES A L'IDENTIQUE : memes * selecteurs, memes declarations, meme ordre relatif, donc meme specificite et meme * resultat. Ce n'est PAS une reecriture. Il conserve donc le prefixe * body.arcprod-tenant et les !important de l'original : ce sont eux qui font * l'autorite du socle face a Bootstrap, et les retirer changerait le rendu. * * POURQUOI UN DEPLACEMENT ET NON UNE REECRITURE (les deux raisons sont mesurees) * 1. Les COULEURS ne se recopient pas en litteral. La bordure du tableau vaut * #e4e8f0 en clair et prend la couleur du texte en sombre : var(--rd-border) ne * se comporte pas pareil dans les deux themes. Garder la reference var() * d'origine reproduit ce comportement par construction, sans avoir a l'elucider. * 2. Les SELECTEURS ne se fusionnent pas. Les passes d'origine ne visent pas les * memes ensembles : l'une couvre .table-reports, .reports-table, .data-table et * [data-ls-table], une autre .table et .data-table, une troisieme ajoute * .reports-table. Les fondre changerait les elements appuyes. * * L'ORDRE RELATIF EST OBLIGATOIRE, PAS COSMETIQUE * Deux regles se disputent font-size sur th A SPECIFICITE EGALE (0.78rem en §1.2 et * 0.73rem en §1.8), toutes deux en !important : seul l'ordre tranche. Le calcul * mesure vaut 0.73rem, ce qui confirme que la plus tardive gagne. Ne JAMAIS reordonner * les blocs de §1 sans remesurer. * * ORDRE DE CHARGEMENT : immediatement apres base.css, avant layout, navbar, custom, * les modules et dark-mode. Comme rien ne se charge entre base.css et ce fichier, le * deplacement ne change la position d'aucune regle dans la cascade globale. * * VERIFIE AVANT LE DEPLACEMENT : l'enumeration des regles de base.css appariant un * tableau, un th ou un td en donne NEUF. Huit sont des regles de tableau et sont ici. * La neuvieme est la regle globale de police, qui cible th et td parmi une vingtaine * d'autres elements : ce n'est pas une regle de tableau, elle RESTE dans base.css, et * elle ne partage aucune propriete avec celles-ci. * * ATTENTION : les tokens de ce runtime sont portes par body, PAS par :root (verifie le * 2026-08-03 : une lecture sur document.documentElement les rend tous vides). Et la * racine est a 15 px, pas 16, ce qui explique les valeurs calculees d'apparence * bricolee : 0.82rem donne 12,3 px, 0.62rem donne 9,3 px. * * @package XHelpers * @version V2 * @author ULB */ /* ===================================================== §1 TABLEAU DE DONNEES Le composant le plus transverse du runtime, et de loin : - 1674 cellules mesurees, dont 86 % partagent la meme apparence - 188 references reparties sur 14 fichiers CSS Le nom canonique est .data-table, PAS .table : le releve du 2026-08-03 compte 13 elements .data-table sur 5 pages contre 1 seul .table, alors que le DOM contient 26 et 106
. Canoniser .table aurait rate presque tous les tableaux de l'application. Les huit blocs ci-dessous viennent de base.css, dans leur ordre d'origine. ===================================================== */ /* §1.1 — cadre du tableau (ex-base.css ligne 68) */ body.arcprod-tenant :is(.table-reports, .reports-table, .data-table, [data-ls-table]) { border-radius: 12px !important; overflow: hidden !important; border: 1px solid var(--rd-border) !important; } /* §1.2 — en-tetes, premiere passe (ex-base.css ligne 74). Son font-size a 0.78rem PERD contre celui de §1.8, a specificite egale mais plus tardif. Conserve tel quel : le retirer changerait le rendu partout ou §1.8 ne s'applique pas (§1.8 ne vise que .table et .data-table, pas .table-reports ni [data-ls-table]). QUATRE valeurs alignees sur la MAJORITE MESUREE le 2026-08-03 (32 des 43 en-tetes du runtime, soit 74 %) : graisse 600 et non 700, interlettrage 0.02em, aucune bordure basse, fond transparent. Cet alignement ne change RIEN aujourd'hui, c'est mesure : les modules recouvrent ces quatre proprietes partout, en !important. Il n'est donc pas un acte de design, c'est la PREPARATION du retrait des redefinitions dans les modules — voir §2. */ body.arcprod-tenant :is(.table-reports th, .reports-table th, .data-table th, [data-ls-table] th) { font-size: 0.78rem !important; font-weight: 600 !important; letter-spacing: 0.02em !important; text-transform: uppercase !important; color: var(--token-text-secondary, #64748b) !important; background: transparent !important; border-bottom: none !important; } /* §1.3 — cellules, premiere passe (ex-base.css ligne 84) */ body.arcprod-tenant :is(.table-reports td, .reports-table td, .data-table td, [data-ls-table] td) { color: var(--token-text-primary, #0f172a) !important; border-color: var(--token-border, #edf1f6) !important; } /* §1.4 — survol de ligne (ex-base.css ligne 89) */ body.arcprod-tenant :is(.table-reports tbody tr:hover, .reports-table tbody tr:hover, .data-table tbody tr:hover, [data-ls-table] tbody tr:hover) { background: var(--bg-secondary, #f8fbff) !important; } /* §1.5 — en-tetes, deuxieme passe, SANS prefixe body (ex-base.css ligne 994). Sa specificite est plus faible que §1.2 : sur .data-table elle perd toujours. Elle reste utile parce qu'elle est la SEULE a couvrir .table, que §1.2 ne vise pas. Son fond est aligne sur la majorite mesuree, comme §1.2 : transparent. */ :is(.table, .data-table) th { background: transparent !important; color: var(--token-text-secondary, #6b7280) !important; border-color: var(--xh-min-border) !important; } /* §1.6 — cellules, deuxieme passe (ex-base.css ligne 1000) */ :is(.table, .data-table) td { border-color: var(--token-border, #eceef1) !important; } /* §1.7 — survol, deuxieme passe (ex-base.css ligne 1004) */ :is(.table, .data-table) tbody tr:hover td { background: var(--bg-secondary, #fafafa) !important; } /* §1.8 — rythme des en-tetes (ex-base.css ligne 1082). C'est CETTE regle qui donne la taille effective : 0.73rem, soit 10,95 px sous la racine a 15 px. Mesure le 2026-08-03. L'interlettrage passe de 0.04em a 0.02em, valeur majoritaire mesuree. Aucun effet aujourd'hui : les modules le recouvrent partout. Voir §1.2 et §2. */ body.arcprod-tenant :is(.table, .data-table) th { font-size: 0.73rem !important; letter-spacing: 0.02em !important; padding: 0.58rem 0.62rem !important; } /* §1.9 — rythme des cellules (ex-base.css ligne 1088) */ body.arcprod-tenant :is(.table, .data-table) td { font-size: var(--xh-compact-text-sm) !important; padding: 0.6rem 0.62rem !important; } /* §1.10 — alignement vertical (ex-base.css ligne 1267) */ body.arcprod-tenant :is(.table, .data-table, .reports-table) :is(th, td) { vertical-align: middle !important; } /* ===================================================== §2 BOUTON A ICONE SEULE Deplace a l'identique de base.css le 2026-08-03. La couche composants est chargee juste apres base.css : sa position dans la cascade globale ne change pas. Mesure avant deplacement sur /contentStats : la variante standard reste a 36 px, les variantes .btn-stats-icon restent a 40 px sans cadre. ===================================================== */ body.arcprod-tenant .xh-icon-only-btn { width: 36px !important; height: 36px !important; min-height: 36px !important; min-width: unset !important; padding: 0 !important; border-radius: 50% !important; display: inline-flex !important; align-items: center !important; justify-content: center !important; flex-shrink: 0; white-space: normal !important; background: transparent !important; border: none !important; box-shadow: none !important; color: var(--token-text-secondary, #6b7280) !important; } body.arcprod-tenant .xh-icon-only-btn i { margin: 0 !important; font-size: 1.15rem !important; } body.arcprod-tenant .xh-icon-only-btn:hover { background: rgba(0,0,0,0.05) !important; opacity: 1 !important; color: var(--token-text-secondary, #4b5563) !important; } /* Variant: strict icon-only (no pill/fill even on hover/focus). */ body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare, body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare:hover, body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare:focus-visible, html[data-theme="dark"] body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare, html[data-theme="dark"] body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare:hover, html[data-theme="dark"] body.arcprod-tenant .xh-icon-only-btn.xh-icon-only-btn--bare:focus-visible { background: transparent !important; border: 0 !important; box-shadow: none !important; border-radius: 0 !important; } /* ===================================================== §3 TROIS DECLARATIONS DE §1 SONT MORTES EN PRATIQUE Mesure du 2026-08-03, a ne pas refaire : modifier dans §1 la graisse, l'interlettrage et la bordure basse des en-tetes ne change RIEN. Zero cellule sur 1717, sur les six pages qui portent un tableau. Un module les recouvre partout, chaque fois en !important. Sur /forum par exemple, forum_home.css impose graisse 600, interlettrage 0.08em et bordure basse supprimee. propriete valeur ecrite ici ce qui s'affiche reellement th font-weight 700 (§1.2) 600, impose par le module th letter-spacing 0.04em (§1.8) 0.08em, impose par le module th border-bottom 1px solid (§1.2) aucune, imposee par le module CONSEQUENCE SUR L'ORDRE DES OPERATIONS. Il serait faux de croire qu'aligner ces valeurs sur la majorite mesuree est un acte de design a valider visuellement : cela ne change rien tant que les modules recouvrent. Le vrai alignement passe par le RETRAIT des redefinitions dans les modules, et c'est seulement a ce moment-la que les valeurs ecrites ici deviennent visibles. Donc : 1. regler le canon ici (sans effet visible, donc sans risque) ; 2. PUIS retirer les redefinitions d'un module ; 3. la validation visuelle porte sur l'etape 2, pas sur l'etape 1. Ce que cet ecart apprend : le canon existe bien dans l'application, mais il est produit par un EMPILEMENT de modules, jamais par une source unique. C'est exactement ce que ce fichier entreprend de renverser, et cela explique pourquoi le renversement ne peut pas se voir avant que les modules aient maigri. Valeurs majoritaires mesurees, a inscrire ici quand on entamera un module : graisse 600, interlettrage 0.02em, aucune bordure basse. ===================================================== */ /* ===================================================== §3 COMPOSANTS DELIBEREMENT ABSENTS Chacun pour une raison mesuree, pas par oubli. BOUTON. Le releve du 2026-08-03 compte 776 boutons dans le runtime, dont 26 seulement portent .btn, pour 72 noms de classes distincts et 58 classes locales a une ou deux pages. Il n'existe donc pas un bouton redefini N fois, mais une trentaine de boutons differents definis chacun une fois. Les fondre en un seul change l'apparence de la plupart : c'est un acte de design, traite a part. BADGE. 350 elements, mais la majorite affichee (54 %) est concentree sur DEUX pages : ce sont les badges .bg-light d'une seule vue volumineuse qui font la masse, pas une apparence partagee. La mesure dit que ce composant n'est pas mur pour un arbitrage a la majorite. CHAMP DE FORMULAIRE (29 % de majorite sur 24 elements) et ETIQUETTE (35 % sur 20) : trop disperses pour qu'une majorite ait un sens. ALERTE : 6 elements pour 4 apparences. L'echantillon ne permet pas de conclure. BOUTON ICONE SEULE (.xh-icon-only-btn, 79 elements sur 23 pages) : deja canonique, defini une seule fois dans base.css. A deplacer ici un jour, avec sa propre mesure. ===================================================== */