*/ /* La transición de un control, sin `all` --------------------------------- El portal escribía `transition:var(--amr-tr-ui, all .15s)` en 208 sitios — casi siempre el mismo botón, el mismo toggle de tema y el mismo chip, copiados de módulo en módulo. `all` no es "lo que cambie": es LITERALMENTE toda propiedad animable, incluidas las de layout. Basta que un estado toque el `padding`, el `height`, el `font-size` o el `gap` —y varios lo hacen— para que el navegador tenga que RE-MEDIR la página en cada fotograma de un hover. Es la clase de animación que nadie pidió y que solo se nota como tirón. Esta lista es lo que un control sí quiere transicionar: color, marco, sombra, opacidad, el gesto (transform) y el brillo. Nada que mueva el layout. `transform` va dentro a propósito — sacarlo dejaría el press sin transición, porque una declaración de `transition` reemplaza a la de anim.css, no se suma a ella. Se usa como `transition:var(--amr-tr-ui, all .15s)`: el valor de reserva mantiene el comportamiento de antes en una página que no cargue tokens.css. */ --amr-tr-ui: background-color var(--amr-dur-fast), color var(--amr-dur-fast), border-color var(--amr-dur-fast), box-shadow var(--amr-dur-fast), opacity var(--amr-dur-fast), transform var(--amr-dur-fast), filter var(--amr-dur-fast), fill var(--amr-dur-fast), stroke var(--amr-dur-fast); /* Capas (z-index) -------------------------------------------------------- */ --z-base:1; --z-card-accent:2; --z-topbar:1000; --z-popover:100; --z-overlay:2000; /* Hoja/modal del kit (.ui-modal lo referencia). POR ENCIMA de la navegación: el rail y la barra inferior viven en 1200 y las hojas propias de nav.js en 1300, así que con 1200 empataba con la barra del móvil y —al montarse esta después en el — la barra tapaba el pie del diálogo: en un teléfono el botón de guardar quedaba debajo de «Hoy · Rutas · Mostrador». Un diálogo bloquea la pantalla; si algo se tapa, se tapa la navegación. */ --z-modal:1400; /* LOS TRES VELOS (tanda 3, 23 sep 2026): había 58 reglas de velo con 26 valores distintos para la misma idea. Ahora son tres, por lo que tapan: --velo-suave · menús, cajones y avisos que dejan ver lo de detrás; --velo · una ventana (modal) que pide atención; --velo-visor · un visor de fotos o un calendario a pantalla completa. En claro, del color de la tinta del tema; en oscuro, negro (la tinta es clara y no sirve de velo). */ --velo-suave:rgba(17,18,20,.4); --velo:rgba(17,18,20,.5); --velo-visor:rgba(17,18,20,.9); /* Los interruptores: la pista apagada y la perilla (anim.css los pinta). */ --tgl-off:#d9dde2; --tgl-knob:#1c1e21; /* La verificación en dos pasos (assets/verificar-cangrejo.js) va POR ENCIMA de la hoja que la abre, y las hojas de módulo suben mucho más que `--z-modal`: la lista del Modo Entrega —donde vive el borrado en el celular— está en 9600, y los overlays de Rutas activas llegan a 10100. Con el valor de un modal normal la ventana se pintaba DETRÁS y el borrado parecía no responder. Por debajo de la alarma y del logro a pantalla completa (99998/99999), que sí deben ganarle a todo. */ --z-verificacion:10600; --z-toast:9999; /* Layout ----------------------------------------------------------------- */ --maxw-frame:1600px; /* ancho máximo del lienzo del portal */ --maxw-read:680px; /* ancho máximo cómodo de lectura */ /* Objetivo táctil mínimo. Era 42 y pasa a 44 (ago 2026) por dos razones: es lo que ya decía `--alto-control-movil` justo abajo —había dos números para la misma idea— y es contra 44 contra lo que se mide. El cambio no mueve nada hoy: este token no lo usaba ni un selector del portal, que es exactamente el defecto. Los controles medidos a 390 px iban de 20 a 39 px. */ /* ── EL NOTCH, con nombre ──────────────────────────────────────────────── `env(safe-area-inset-*)` se escribía a mano 208 veces en 53 archivos y en DIEZ formas distintas, sin un solo token. Aquí están los cuatro lados. Y una advertencia que cuesta una pantalla entender: `max(14px, env(top))` NO deja 14px de aire bajo la isla dinámica — deja CERO. En un iPhone el inset superior vale 59px, así que el max() se queda con 59 y el contenido arranca justo en el borde de la isla, pegado. Lo que deja aire es SUMAR: `calc(env(top) + 14px)`. En un teléfono sin notch env() vale 0 y las dos formas dan exactamente 14px, así que cambiar de una a otra no mueve nada donde no hay notch y arregla justo donde lo hay. Abajo es distinto y por eso `max()` SÍ vale ahí: el inset inferior (34px en los iPhone con gesto) es la franja del indicador, que ya está vacía. Ponerse a 34px es apoyarse en su borde, no meterse debajo. */ --safe-top:env(safe-area-inset-top, 0px); --safe-bottom:env(safe-area-inset-bottom, 0px); --safe-left:env(safe-area-inset-left, 0px); --safe-right:env(safe-area-inset-right, 0px); --tap-min:44px; /* Aire que una tarjeta necesita alrededor para que su sombra no se recorte contra el borde de un panel con scroll. Lo usaban anim.css y barra-controles.css con reserva `,14px`, sin que el token existiera. */ --tarjeta-aire:14px; /* Canalón lateral · el margen a los lados de TODA pantalla ----------------- UN solo par de valores para el aire lateral del portal: el marco de la página (`main`/`.wrap`/`.main`), la topbar, las barras fijas (paginador, acciones) y los filtros del kit se alinean con él. Se ajusta AQUÍ y cambia el portal entero; ningún módulo vuelve a escribir su canalón a mano. Ago 2026 (orden de Samuel): el aire lateral se estrecha mucho y el lienzo se ensancha. Eran DOS márgenes distintos confundidos en uno: · El CANALÓN (padding del marco): 24px en escritorio y 12–16 en móvil, repetido a mano en 47 páginas. Pasa a 12 y 10. Es el que se ve en un portátil, donde la ventana mide menos que el lienzo y el padding ES todo el margen. · El LIENZO (--maxw-frame): topado en 1280px. En un monitor de 1920 dejaba 320px muertos a CADA lado y bajar el canalón ahí no cambiaba nada, porque el margen no lo ponía el padding sino el tope de ancho. Sube a 1600px, que es lo que de verdad estira el contenido en pantalla grande. Las dos cosas a la vez: en portátil se gana por el canalón, en monitor por el lienzo. Tocar solo una deja la mitad del portal igual que estaba. */ --pad-x:12px; /* canalón lateral en escritorio (antes 24, a mano) */ --pad-x-movil:10px; /* canalón lateral en móvil (antes 12–16, a mano) */ /* Puntos de corte --------------------------------------------------------- LOS TRES DE ABAJO SON LOS ÚNICOS PARA PANTALLAS NUEVAS. No se inventan más. Los tres coinciden con los que ya usa la mayoría del portal (520 en 65 reglas, 760 en 48, 1100 en 11), así que no imponen nada nuevo: recogen lo que ya se decidió a base de repetirlo. PERO el portal tiene hoy 16 cortes reales, no 3, y la diferencia no es descuido en su mayoría (jul 2026, al ir a unificarlos): · Los pares n / n+1 —640/641, 760/761, 720/721, 980/981, 899/900, 1023/1024, 1100/1101, 1180/1181— son CORRECTOS: así las dos reglas no se solapan en el píxel de frontera. Contarlos como duplicados fue un error de lectura de la primera auditoría, repetido en la segunda. · 600 (16 reglas), 720 (12), 820 (6), 900 (15), 420 (3) tienen peso propio: son decisiones de diseño de pantallas concretas, no despistes. · 380 es «móvil pequeño» de verdad (iPhone SE/mini). Subirlo a 420 apretaría el layout de un iPhone 14, que mide 390. Se queda. · 680 y 1400 son de `etiquetas-producto`, declarada EXCEPCIÓN por Samuel: dibuja etiquetas en milímetros y el token de pantalla no le aplica. Bajar de 16 a 3 no es limpiar: es rediseñar dónde rompe cada pantalla, y hacerlo a ciegas descuadra el portal en anchos que nadie mira hasta que un usuario los sufre. Lo que sí se hizo fue absorber los HUÉRFANOS —los que aparecían una o dos veces sin razón—: 559→560, 1000→980, 400→420, 620→640. */ --breakpoint-mobile:520px; --breakpoint-tablet:760px; --breakpoint-wide:1100px; /* Anchos de bloque interno ------------------------------------------------ La auditoría encontró 63 anchos distintos, 37 de ellos usados UNA sola vez. El de PÁGINA ya estaba resuelto (1280 en las 41); el desorden estaba dentro: 520, 560, 640, 720, 760, 900… para lo mismo. DOS, no tres (decisión de Samuel, jul 2026). La propuesta eran tres —diálogo 480 / formulario 640 / detalle 960—; se eligió reducir a dos para que al construir una pantalla nueva no haya que decidir nada. El precio aceptado: un formulario de una columna queda más ancho de lo ideal para leer. Si algún día molesta, se corta con --maxw-read (680) sin tocar esto. EL DIÁLOGO ES 520, no 480 (ajustado al aplicarlo). Se eligió 480 sobre una lista de valores, sin el desglose delante; al tokenizar los once diálogos del portal apareció el dato: 520 es lo que ya usaban DIECISÉIS reglas y 480 solo tres. O sea que 520 no es una preferencia, es lo que el portal decidió a base de repetirlo, y es lo que el equipo lleva tiempo viendo. Estrechar once diálogos 40 px no le daba nada a nadie. Que cambiarlo haya sido editar ESTA línea, y no once archivos, es exactamente para lo que se tokeniza. */ --maxw-dialogo:520px; /* confirmar, avisar: una frase y dos botones */ --maxw-contenido:900px; /* todo lo demás: formulario, detalle, tabla */ /* Alturas de control ------------------------------------------------------ Densidad: compacta en escritorio (se ve más de un vistazo), cómoda en móvil (se trabaja con prisa y con el pulgar). Nunca por debajo de --tap-min. */ --alto-control:36px; /* botón, campo, select en escritorio */ --alto-control-movil:44px; --alto-fila:36px; /* fila de tabla en escritorio */ --alto-fila-movil:44px; /* Foco -------------------------------------------------------------------- El anillo del portal es `--ring`, definido arriba con los dos temas y usado por el kit y los módulos. Aquí vivía además `--foco-anillo`, con la misma idea y otro número (38 % contra el 28 % de `--ring`), y sin que lo llamara ni un selector: dos nombres para lo mismo, que es como acaban existiendo dos anillos distintos. Se retira; el que manda es `--ring`. El anillo de TECLADO no se dibuja con esto, sino con la regla `!important` de `anim.css` (§3a-bis), que gana a los `outline:none` que cada módulo escribió por su cuenta. Eso es a propósito y está comprobado con Tab real: ninguna pantalla del portal se queda sin señal de foco. */ } /* ── El canalón se estrecha SOLO en el token, no en 29 pantallas ─────────── `--pad-x-movil` existía desde ago 2026 y cada pantalla tenía que acordarse de bajarse a él en su media query. La cuenta al revisarlo (ago 2026): de 52 páginas, 23 lo aplicaban solo a la topbar —el marco se quedaba en los 12 de escritorio— y 6 no lo nombraban nunca. O sea que el canalón de móvil valía para menos de la mitad del portal, y la diferencia no se ve pero se acumula: son 4 px de ancho útil en la pantalla donde menos sobra. Redefinir el token aquí lo arregla de una vez y para lo que venga: TODA regla que ya escribe `var(--pad-x)` —las 43 topbars y los 45 marcos— se estrecha sola en móvil, sin tocar una sola pantalla. Las que ya nombran `--pad-x-movil` en su media query siguen igual: piden el mismo valor. Se puede porque `--pad-x` NO tiene otro uso: las 100 apariciones del portal son canalón horizontal (topbar o marco). Se comprobó una a una antes de moverlo; si algún día se usa para otra cosa, esto deja de valer. El corte es 760 —el `--breakpoint-tablet` de arriba, que es el que ya usan 26 de las 46 páginas que lo aplican— y no se escribe con la variable porque una media query no puede leer una custom property. */ @media (max-width:760px){ :root{ --pad-x:var(--pad-x-movil); } } /* ═══════════════════════════════════════════════════════════════════════════ BASE MÍNIMA Esto NO son tokens, y va aquí a propósito: `tokens.css` es la única hoja que cargan las 41 páginas. `ui.css` falta en 16, así que una regla puesta allí dejaría fuera justo a las que peor están. El foco de teclado no se veía en 34 de 41 páginas (defecto D-03). Quien no usa ratón —o usa el portal desde un teclado en el mostrador— no sabía dónde estaba parado. `:focus-visible` solo se dibuja cuando el navegador entiende que el foco viene del teclado, así que no ensucia el clic con el ratón. ═══════════════════════════════════════════════════════════════════════════ */ :where(a, button, input, select, textarea, summary, [tabindex]):focus-visible{ outline:2px solid var(--gold); outline-offset:2px; border-radius:var(--radius-sm,8px); } /* ── Rebote y pull-to-refresh (ago 2026) ────────────────────────────────── 37 de 49 páginas no declaraban `overscroll-behavior` en ningún sitio. En la PWA instalada eso son dos cosas molestas: el pull-to-refresh del navegador se dispara al arrastrar hacia abajo en una lista que ya está arriba, y el rebote de un panel interno se encadena a la página de detrás. `contain` corta las dos y NO estorba al pull-to-refresh propio del portal: ese está hecho con `touchmove` + `preventDefault` (ver `app-ios.js`), no con el rebote nativo. Lo que se apaga es el del navegador, que es el que sobra. SOLO el eje Y, a propósito: `overscroll-behavior-x:contain` en la raíz apaga el gesto de «atrás» del sistema en Android, que es navegación que la gente usa. El eje X se contiene donde toca —en el contenedor con scroll de una tabla— y eso va en la pantalla, no aquí (ver §14.4 del sistema de diseño). */ html{ overscroll-behavior-y:contain; } /* `:where()` tiene especificidad CERO: cualquier regla de página que ya defina su propio foco sigue mandando. Esto solo cubre a quien no tenía ninguno. */ /* Los resortes del manual, dibujados de verdad donde el navegador sabe (`linear()`): los mismos que usa el manual de marca. */ @supports (transition-timing-function: linear(0, 1)){:root{ --amr-ease-spring:linear(0, 0.0307, 0.1096, 0.2192, 0.3448, 0.4748, 0.6004, 0.7155, 0.8162, 0.9005, 0.9679, 1.0191, 1.0553, 1.0786, 1.091, 1.0948, 1.092, 1.0846, 1.0743, 1.0624, 1.0501, 1.0382, 1.0272, 1.0176, 1.0096, 1.0032, 0.9983, 0.9948, 0.9926, 0.9914, 0.991, 0.9913, 0.992, 0.9929, 0.9941, 0.9952, 0.9964, 0.9974, 0.9983, 0.9991, 0.9997, 1.0002, 1.0005, 1.0007, 1); --amr-ease-press:var(--amr-ease-spring); --amr-ease-out:linear(0, 0.0229, 0.0809, 0.1609, 0.2526, 0.3486, 0.4435, 0.5334, 0.616, 0.69, 0.7548, 0.8104, 0.8573, 0.896, 0.9274, 0.9523, 0.9717, 0.9864, 0.9972, 1.0049, 1.01, 1.0131, 1.0147, 1.0152, 1.0148, 1.014, 1.0128, 1.0114, 1.0099, 1.0085, 1.0071, 1.0059, 1.0047, 1.0038, 1.0029, 1.0022, 1.0016, 1.0011, 1.0007, 1.0004, 1.0002, 1, 0.9999, 0.9999, 1); }}