/* tema.css — la paleta de ViewHighWay sobre el visor propio.
 *
 * POR QUE ESTE FICHERO EXISTE Y NO SE EDITA ohif\platform\ui-next\src\tailwind.css
 * ------------------------------------------------------------------------------
 * Ese fichero va svn:ignore'd y lo rehace tools\Preparar-OHIF.ps1 desde cero: cualquier cambio
 * alli desaparece en la siguiente preparacion SIN avisar, y ademas recrearia el fork que el
 * axioma "aditivo" prohibe. Aqui la paleta esta versionada y viaja con el codigo.
 *
 * POR QUE ":root:root" Y NO ":root"  (dos hechos medidos que juntos son un fallo silencioso)
 * ------------------------------------------------------------------------------------------
 *  1. OHIF va con Tailwind 3.2.4, asi que su "@layer base" se compila y DESAPARECE: en
 *     app.bundle.css los tokens acaban en un ":root{...}" PLANO. Un ":root" propio tiene la
 *     misma especificidad y solo ganaria si llegase despues.
 *  2. En el index.html del build, app-config.js va ANTES del <link> de app.bundle.css. O sea
 *     que "el que llega despues" no lo controlamos del todo desde el lado del visor.
 *  Duplicar el selector (":root:root", especificidad 0-2-0) gana pase lo que pase con el orden.
 *  Aun asi, tools\Compilar-Visor.ps1 inyecta su <link> como ULTIMO elemento antes de </head> y
 *  ABORTA si no es el ultimo stylesheet: cinturon y tirantes, porque el sintoma de fallar aqui
 *  es "la paleta no se aplica" sin un solo error en consola.
 *
 * EL TONO
 * -------
 * 210 es el tono de los tres colores de la marca:
 *   #003366 = hsl(210 100% 20%)   #336699 = hsl(210 50% 40%)   #6699CC = hsl(210 50% 60%)
 * Los valores van en el formato que espera Tailwind: "H S% L%" sin hsl(), porque las utilidades
 * se compilan como hsl(var(--token) / <alpha>).
 */

:root:root {
  /* Azules de la marca */
  --primary: 210 50% 60%;      /* #6699CC — antes 214 98% 60% */
  --secondary: 210 50% 40%;    /* #336699 — antes 214 65% 36% */
  --accent: 210 100% 20%;      /* #003366 — antes 217 79% 24% */
  --ring: 210 50% 60%;         /* el foco, igual que --primary */

  /* Superficies. Todas son navy muy oscuro: sobre el negro del fondo tienen que leerse como
     paneles, no como otro negro. */
  --card: 210 45% 10%;         /* antes 234 64% 10% */
  --popover: 210 60% 15%;      /* antes 219 90% 15% */
  --input: 210 45% 30%;        /* antes 236 52% 30% */
  --muted: 210 45% 10%;        /* antes 234 64% 10% */

  /* Textos secundarios y realces */
  --muted-foreground: 210 30% 68%;  /* antes 200 46% 65% — 9,07:1 sobre negro */
  --highlight: 210 60% 66%;         /* antes 191 74% 63% — 8,38:1 sobre negro */

  /* 🔴 --background SE QUEDA NEGRO (0 0% 0%). Una imagen medica se lee sobre negro; eso no es
     estetica, y por eso no aparece aqui: no se toca ni por descuido. */

  /* 🔴 --primary-foreground NO se toca AQUI (se queda en 0 0% 98%). Ver el bloque de abajo:
     ponerlo en navy a nivel de :root dejaria los tooltips y la barra de herramientas con el
     texto invisible. */
}

/* ---------------------------------------------------------------------------------------------
 * Legibilidad del texto sobre un relleno --primary  (WCAG AA, 4,5:1)
 * ---------------------------------------------------------------------------------------------
 * El problema: #6699CC es claro, y con la tinta casi blanca de serie (0 0% 98%) el texto sobre un
 * boton primary se queda en 2,88:1 sobre el relleno opaco y en 3,59:1 sobre el del boton real
 * (medido en la pagina viva, no calculado). El azul de serie de OHIF tampoco llegaba (3,98:1
 * medido en el mismo boton), asi que esto viene de fabrica, pero se arregla ya que tocamos.
 *
 * 🔴 Lo que NO vale: poner --primary-foreground en navy dentro del ":root:root" de arriba.
 * OHIF usa ese token para DOS cosas incompatibles:
 *   (a) tinta SOBRE un relleno primary   — Button.tsx, Checkbox.tsx, Calendar.tsx;
 *   (b) texto claro sobre fondo OSCURO   — Tooltip.tsx:23 lo pone junto a "bg-muted", y
 *       Toggle.tsx:8 lo usa como color por defecto del boton de barra sobre negro.
 * Medido: la tinta navy sobre --muted da 1,07:1 y navy/80 sobre negro 1,08:1. O sea, tooltips y
 * botones de la barra con el texto INVISIBLE, y sin un solo error en consola.
 *
 * Lo que se hace: redefinir el token SOLO en los elementos que llevan de verdad un relleno
 * primary. Como las custom properties heredan, "text-primary-foreground" de ese elemento y de sus
 * hijos resuelve a la tinta oscura, y todo lo demas sigue viendo el valor claro de :root:root.
 * Se cambia el TOKEN y no "color" para no pelearse con las variantes (hover, disabled...).
 *
 * Sobre la fragilidad, que la hay: estos selectores citan clases de Tailwind que nacen en ohif\
 * (que va svn:ignore'd y lo rehace Preparar-OHIF.ps1). Si un dia OHIF cambia el "/85" del boton,
 * la regla deja de aplicar. El modo de fallo es BENIGNO a proposito: se vuelve al 3,59:1 de hoy,
 * no aparece texto invisible. Por eso se acota a los rellenos opacos o casi (100% y 85%) y se
 * dejan fuera los tintes bajos (/10 a /80), que son fondos oscuros donde la tinta clara es la
 * correcta.
 *
 * Contrastes medidos con la tinta hsl(210 77% 7%) = #041220 (el #04121f pedido, en HSL):
 *   sobre bg-primary opaco #6699CC ............ 6,29:1  (antes 2,88:1)
 *   sobre bg-primary/85 del boton real ........ 5,06:1  (antes 3,57:1)
 *   sobre bg-primary/85 contra negro puro ..... 4,68:1  (antes 3,87:1)  <- el peor caso
 *
 * Quedan fuera, y se sabe: el "tick" del Checkbox y el dia elegido del Calendar pintan el relleno
 * desde una variante data-[...], cuyo nombre de clase no se puede distinguir por selector de los
 * tintes bajos que lleva el MISMO elemento. Son glifos, no texto; el umbral que les aplica es el
 * 3:1 de objetos graficos.
 */
[class~='bg-primary'],
[class~='bg-primary/85'] {
  --primary-foreground: 210 77% 7%;
}