/* ============================================================================ LAYER ONE · TOKENS DE TEMA — LA ÚNICA FUENTE DE COLOR DE LA PLATAFORMA ============================================================================ ESTE ARCHIVO ES EL KIT DEL DISEÑADOR. Si querés cambiar cómo se ve la plataforma entera, se cambia ACÁ y en ningún otro lado. POR QUÉ EXISTE -------------- Hasta el 21/08 el color vivía en DOS lugares con nombres distintos y sin ninguna referencia entre sí: el objeto `tailwind.config` embebido en `base.html` (15 colores, del que dependen 663 clases de utilidad) y el bloque `:root` de `app.css` (11 variables `--l1-*`, de las que dependen 18 clases de componente). Los valores coincidían por casualidad y el que mandaba era el JavaScript — o sea, el peor lugar posible para que lo toque alguien que diseña. Un archivo de tokens suelto no arreglaba nada mientras el config de Tailwind tuviera hexes propios. Ahora: acá están los valores, `base.html` DERIVA su config de estos tokens y `app.css` los usa. Una sola definición, dos consumidores. POR QUÉ LOS VALORES ESTÁN EN CANALES (`11 11 13`) Y NO EN HEX ------------------------------------------------------------- Medido: **69 de las 694 clases de color usan modificador de opacidad** (`text-muted/70`, `border-edge/40`, `bg-good/5`…). Tailwind solo puede aplicar ese modificador si el color llega con la sintaxis de canales: :root { --l1-muted: 139 139 148; } <- canales, NO #8b8b94 colors: { muted: 'rgb(var(--l1-muted) / )' } Con un hex, el modificador **se ignora en silencio**: la clase resuelve, la pantalla no se rompe, y el color sale opaco donde tenía que salir al 40%. Un fallo silencioso en una hoja de estilos es de los que nadie reporta. Para no obligar a nadie a escribir `rgb(var(--x))` a mano, cada token tiene al lado su alias ya armado (`--c-*`), DERIVADO del canal. **El valor se escribe una sola vez.** Para cambiar un color, se toca el canal. CÓMO PASAR DE HEX A CANALES --------------------------- `#0b0b0d` -> `11 11 13`. Cada par hexadecimal a decimal, separados por espacios (sin comas). El comentario de cada línea trae el hex original. LAS DOS REGLAS DEL KIT ---------------------- 1. **Todo color va acá.** Un hex suelto en `app.css` o en una plantilla es una fuga que reintroduce exactamente el problema que este archivo cerró. 2. **No se renombran clases ni `id`.** Son el contrato con el JavaScript y hay un guard en la suite que se pone rojo si se rompen. ========================================================================= */ :root { /* ---- Superficies ------------------------------------------------------- De más oscuro a más claro: la página, el header, las tarjetas, los controles secundarios. La caja de CPU tiene su propio tono porque vive dentro del header y necesita separarse de él sin usar un borde fuerte. */ --l1-bg: 11 11 13; /* #0b0b0d fondo de página */ --l1-bg-header: 16 16 20; /* #101014 header persistente, inputs */ --l1-card: 21 21 24; /* #151518 tarjetas y paneles */ --l1-card-2: 27 27 32; /* #1b1b20 botones secundarios, chips */ --l1-card-cpu: 19 19 23; /* #131317 caja de CPU del header */ /* ---- Bordes y separadores --------------------------------------------- `border` es el borde general; `border-2` es más claro y se usa en los badges neutros, donde el borde tiene que leerse sin gritar; `row` separa filas de tabla y es el más tenue de los tres. */ --l1-border: 42 42 49; /* #2a2a31 */ --l1-border-2: 63 63 72; /* #3f3f48 */ --l1-row: 34 34 39; /* #222227 */ /* ---- Texto ------------------------------------------------------------- Tres niveles y no dos. `muted` es el más apagado y es, de lejos, el token más usado de la plataforma (366 clases): rótulos, ayudas y todo lo que acompaña a un dato sin ser el dato. */ --l1-text: 237 237 240; /* #ededf0 texto principal */ --l1-text-2: 169 169 178; /* #a9a9b2 texto secundario */ --l1-muted: 139 139 148; /* #8b8b94 rótulos y ayudas */ /* ---- Identidad --------------------------------------------------------- `accent` es el rojo de marca: tabs activas, links, la línea de CPU. `primary` es el rojo LLENO de los botones de acción (texto blanco). `accent-soft` es el hover y el texto sobre fondos rojizos suaves. */ --l1-accent: 255 90 95; /* #ff5a5f */ --l1-accent-soft: 255 138 143; /* #ff8a8f */ /* El rojo LLENO de los botones de acción, con texto blanco encima. **El valor lo decide el CONTRASTE, no el gusto**: `#e8494f` daba 3,82:1 sobre blanco y AA pide 4,5 para texto normal, así que el rótulo del botón primario —el de la acción de más impacto de la plataforma— no se leía en un monitor con brillo bajo. `#e42930` da **4,51:1** (medido con la fórmula de luminancia relativa de WCAG 2.1). Si algún día se toca, se vuelve a medir: un primario que baja de 4,5 rompe la accesibilidad sin romper nada visible, que es como se coló el anterior. */ --l1-primary: 228 41 48; /* #e42930 contraste 4,51:1 sobre --on-primary */ --l1-accent-border: 92 42 46; /* #5c2a2e borde de la acción con énfasis */ /* ---- Semánticos -------------------------------------------------------- Verde = sano y confirmado. Ámbar = pendiente, alarma abierta, «hay que mirarlo». Alerta = el rojo del dato malo y de la línea de umbral; es un rojo distinto del de marca a propósito, para que «esto es de Layer One» y «esto está mal» no se confundan. */ /* --- Paleta de SERIES de gráfico (25/08) ------------------------------------- Desaturada y armónica, estilo NOC (Grafana/Datadog). El problema que resuelve está medido a ojo por el operador: con los colores de marca —rojos, rosas, dorados y verdes de alto contraste sobre negro— nueve series se vuelven spaghetti y no se pueden distinguir, y cansan la vista en minutos. Van EN CANALES como todo el resto del archivo: el alfa se aplica con barra (`rgb(var(--l1-graf-1) / .1)`), nunca convirtiendo a `rgba`. Los grises fríos del final son deliberados: «otros» y «sin región» tienen que verse como lo que son —un agregado sin identidad— y no competir con una red concreta. */ --l1-graf-1: 56 189 248; /* #38bdf8 cian suave */ --l1-graf-2: 45 212 191; /* #2dd4bf verde azulado */ --l1-graf-3: 129 140 248; /* #818cf8 violeta apagado */ --l1-graf-4: 251 191 36; /* #fbbf24 ámbar suave */ --l1-graf-5: 244 114 182; /* #f472b6 rosa apagado */ --l1-graf-6: 163 230 53; /* #a3e635 lima apagado */ --l1-graf-7: 148 163 184; /* #94a3b8 gris frío claro */ --l1-graf-8: 100 116 139; /* #64748b gris frío */ /* El fondo del área de gráfico: carbón, no negro absoluto. */ --l1-graf-fondo: 27 30 36; /* #1b1e24 */ --l1-ok: 52 211 153; /* #34d399 */ --l1-ok-border: 42 92 74; /* #2a5c4a */ --l1-warn: 240 182 74; /* #f0b64a */ --l1-warn-border: 110 74 42; /* #6e4a2a */ --l1-alert: 255 122 114; /* #ff7a72 */ --l1-danger-border: 92 42 42; /* #5c2a2a zona de impacto */ /* ---- Informativo neutro ------------------------------------------------ El badge que NO es un estado: versión de RouterOS, conteo de reglas, «fuera del ruleset». En la paleta anterior esto era violeta; en la gama Layer One no hay violeta, y pintarlos de rojo los haría leer como alarma. Gris claro sobre borde `border-2`, tal como el mockup aprobado (61a). */ --l1-info: 217 217 224; /* #d9d9e0 */ /* El texto que va ENCIMA de `--primary` (botones llenos). Es un token y no un `#fff` suelto porque si mañana el primario se aclara, el texto de arriba tiene que poder cambiar con él — y porque la regla de este archivo es que no haya ni un hex afuera. */ --l1-on-primary: 255 255 255; /* #ffffff */ /* ---- Alias derivados --------------------------------------------------- Para usar un token en CSS común sin escribir `rgb(var(...))` a mano. **No son un segundo valor**: se derivan de los canales de arriba, así que cambiar el canal los cambia a los dos. */ --c-bg: rgb(var(--l1-bg)); --c-bg-header: rgb(var(--l1-bg-header)); --c-card: rgb(var(--l1-card)); --c-card-2: rgb(var(--l1-card-2)); --c-card-cpu: rgb(var(--l1-card-cpu)); --c-border: rgb(var(--l1-border)); --c-border-2: rgb(var(--l1-border-2)); --c-row: rgb(var(--l1-row)); --c-text: rgb(var(--l1-text)); --c-text-2: rgb(var(--l1-text-2)); --c-muted: rgb(var(--l1-muted)); --c-accent: rgb(var(--l1-accent)); --c-accent-soft: rgb(var(--l1-accent-soft)); --c-primary: rgb(var(--l1-primary)); --c-accent-border: rgb(var(--l1-accent-border)); --c-ok: rgb(var(--l1-ok)); --c-ok-border: rgb(var(--l1-ok-border)); --c-warn: rgb(var(--l1-warn)); --c-warn-border: rgb(var(--l1-warn-border)); --c-alert: rgb(var(--l1-alert)); --c-danger-border: rgb(var(--l1-danger-border)); --c-info: rgb(var(--l1-info)); --c-on-primary: rgb(var(--l1-on-primary)); /* ---- Tipografía -------------------------------------------------------- Monoespaciada para IPs, códigos de regla, timestamps y contadores: son datos que se comparan de a columnas, y una proporcional los desalinea. */ --l1-mono: ui-monospace, "SFMono-Regular", Menlo, Monaco, monospace; --l1-sans: system-ui, -apple-system, "Segoe UI", Roboto, sans-serif; /* ---- TAMAÑO BASE: LA PERILLA DE TODA LA ESCALA ------------------------- `app.css` se lo aplica a `html`, y a partir de ahí **toda** la tipografía de la plataforma sale en `rem`: la escala de Tailwind (`text-xs` .75rem, `text-sm` .875rem…), las clases de componente de `app.css` y los dos escalones chicos de abajo. Cambiar este número mueve la UI entera. POR QUÉ NO ES 16px ------------------ El default del navegador son 16px, y con eso la UI **se leía solo con el zoom al 150%** en el 2K del operador (medido el 24/08): la mitad de los rótulos vivían en 10-12px reales. De dónde sale el 18. El monitor de referencia de la plataforma es 1920×1080; el del operador es 2560 de ancho, o sea 1,33× más pixeles en un panel de tamaño parecido. Un 150% de zoom sobre 2K deja el texto del tamaño FÍSICO que en 1080p daría 150/1,33 = **112,5%**, que es 16 × 1,125 = **18px**. O sea: 18 es el número que traslada el confort ya medido del operador al monitor de referencia, y no el gusto del que programa. Es **una** perilla: si en 1080p real todavía queda chico, se sube ACÁ y no hay un segundo lugar que tocar. Lo que NO se hace es volver a escribir un tamaño en px en una plantilla — eso es lo que dejó 91 tamaños fuera de la escala hasta el 24/08. PENDIENTE DECLARADO, fuera de alcance de esta tanda: la versión para navegador de CELULAR. Es tanda propia de layout y breakpoints; esta escala en `rem` es su prerequisito, no su reemplazo. --------------------------------------------------------------------- 26/08: el 18 fijo pasa a SALIR DE LA PANTALLA, sin perderse. El pedido: *«que se ajuste mejor, así es independiente de la pantalla o la resolución a la cual se vea»*. Un px clavado se ve grande en 1080p y chico en 4K — el confort calibrado valía para UN monitor. La cuenta preserva la calibración de arriba. El operador mira con 150% de zoom sobre 2560, así que su viewport CSS real es 2560 / 1,5 = **1707px**, y a ese ancho `1.05vw` da 1707 × 0,0105 = **17,9px**: exactamente el 18 que ya estaba medido. Lo que cambia es el resto de las pantallas. viewport 1520px o menos -> 16px (piso: por debajo se vuelve ilegible) viewport 1707px -> 18px (el del operador, sin cambios) viewport 1920px -> 20px viewport 2100px o más -> 22px (techo: más grande no aporta) Sigue siendo **una** perilla, y sigue sin haber tamaños en px en las plantillas: lo que se toca acá son los tres números del `clamp`. */ --l1-fs-base: clamp(16px, 1.05vw, 22px); /* Los dos escalones por DEBAJO de `text-xs`, para rótulos que acompañan a un dato sin ser el dato. Existían como 89 valores arbitrarios en px (`text-[11px]`, `text-[10px]`, `text-[9px]`) que NO escalaban con nada: subir el base los dejaba igual de chicos. Ahora son `rem` y se mueven con la perilla de arriba. Dos y no tres: 9, 10 y 11px eran tres nombres para el mismo tamaño. */ --l1-fs-nota: .72rem; /* ex 11px — el más usado: ayudas y pies de campo */ --l1-fs-micro: .65rem; /* ex 10px y 9px — chips, unidades, marcas al pie */ /* ---- Radios ------------------------------------------------------------ */ --l1-radio-card: 12px; --l1-radio-ctrl: 8px; }