/* ========================================================================== EL MOVIMIENTO · F13 ========================================================================== El usuario pidio «algo de dinamismo, sin ser muy cargante». Esta hoja pone el limite: un solo mando para el tiempo, y una lista corta de cosas que se movian solas y ya no lo hacen. AUDITORIA DE PARTIDA (script en el scratchpad, sobre las 80 hojas del programa mas las 12 del movil): 313 declaraciones de `transition`, de las cuales 20 pasaban de 250 ms (dos de 500, una de 450, una de 400) 26 animaciones INFINITAS 3 animaciones con `both` en el fill-mode 7 hojas respetaban `prefers-reduced-motion`, 72 tenian movimiento y NO lo respetaban POR QUE ESTA EN `@layer ui-controls` Y NO EN `ui-runtime` Misma razon que impresion.css, y es la leccion L27: con `!important` gana la capa mas TEMPRANA. Desde `ui-controls` estas reglas le ganan a armazon.css, a visual-polish.css, a las oleadas y a las 80 hojas de pagina sin tener que contar clases contra selectores como `.content-wrapper > *:not()x9` (0,11,1). El tiempo de las transiciones es una decision de sistema: no deberia poder discutirla una hoja de pagina. ESTA HOJA LA CARGAN LAS DOS PANTALLAS, escritorio y movil, porque el movil tenia lo suyo: los orbes flotantes, `mv2-dots` y tres spinners. ========================================================================== */ /* ========================================================================== EL MANDO DEL TIEMPO · FUERA DE LA CAPA ========================================================================== Igual que --ui-radio con las esquinas: un solo numero para todo el programa. Fuera de `@layer` porque las asignaciones de variables no pueden ir dentro (explicado largo en armazon.css). ========================================================================== */ :root { /* 150 ms es el centro de la horquilla que pide el plan (120-180). Subirlo de 250 incumple F13.1; bajarlo de 100 hace que el hover parezca un salto en seco. */ --ui-movimiento: 150ms; } @layer ui-controls { /* ======================================================================== 1 · NINGUNA TRANSICION PASA DE --ui-movimiento (F13.1) ======================================================================== Habia 20 declaraciones por encima de 250 ms repartidas en 12 hojas: dos `width 0.5s` (barras de progreso), `width 0.45s` y `0.4s` en el dashboard, y una docena de `all 0.3s`. Se hace con UNA regla en vez de editar 20 sitios, por tres razones: - el numero queda en un mando (--ui-movimiento) y se cambia una vez; - las hojas de pagina siguen diciendo QUE propiedad transicionan, que es lo suyo; lo que deja de ser suyo es CUANTO tarda; - la proxima hoja que alguien escriba con `all 0.4s` ya nace acotada. Se toca solo la DURACION. El `transition-delay` no se toca a proposito: hay escalonados que dependen de el y son intencionados. Aqui si se usa `*`, al contrario que con el radio: un radio en cada `td` deja mordiscos visibles, pero una duracion no cambia ni un pixel de la maqueta, solo el tiempo. */ *, *::before, *::after { transition-duration: var(--ui-movimiento) !important; } /* ======================================================================== 2 · LO QUE SE MOVIA SOLO, YA NO (F13.4) ======================================================================== De las 26 animaciones infinitas, la mayoria son SPINNERS y brillos de esqueleto (spin, fa-spin, mv2-spin, gaTableSpin, sv2-shimmer, mv2-dots...) y esas SE QUEDAN: no se mueven solas, se mueven porque hay algo cargando y paran cuando acaba. Son la respuesta a una accion del usuario. Lo que se para es lo que se movia sin que nadie hubiera hecho nada, que es lo que pide F13.4 («nada que se mueva solo, ni parpadeos»). */ /* Las fichas del dashboard subian y bajaban en bucle de 4 s, escalonadas entre ellas. Con Profunda son fichas planas: el dato manda, y un dato que se mueve se lee peor. */ .stat-item, .economic-item, .resumen-item { animation: none !important; } /* El indicador de avisos de la cabecera latia cada 2 s de forma indefinida. Un parpadeo permanente en la esquina de TODAS las pantallas es exactamente lo que el plan llama cargante. El aviso sigue viendose: lleva su color y su numero (F5.5), que no dependen del latido. */ .header-alert-indicator.has-alerts { animation: none !important; } /* Dos parpadeos de alerta mas, con el mismo argumento. */ .alerta-exceso, .list-item.tiene-alerta, .distribucion-total .excede { animation: none !important; } /* Los tres globos de color que flotaban 14 s en bucle detras del login. */ .login-blob { animation: none !important; } /* LO QUE SE QUEDA MOVIENDOSE, Y POR QUE: .parcela-to-clip / .parcela-to-edit / .parcela-to-merge (Ver mapa) .map-btn.location-tracking (movil) Estos laten para senalar un MODO ARMADO que el usuario acaba de activar («esta parcela es la que vas a recortar», «el GPS esta siguiendote»), y paran cuando el modo termina. No es movimiento ambiente: es el acuse de una accion, y quitarlo dejaria el modo activo sin senal. Los spinners y los brillos de esqueleto, igual. */ /* ======================================================================== 3 · NINGUNA ANIMACION DEJA UN `transform` PEGADO EN UN CONTENEDOR (F13.5) ======================================================================== Esto es un seguro contra un bug que ya paso y costo caro: una animacion de entrada con `animation-fill-mode: both` sobre `.content-wrapper` dejaba el `transform` del ultimo fotograma puesto para siempre. Un `transform` crea un CONTEXTO DE APILAMIENTO, y a partir de ahi los modales `position: fixed` se posicionaban respecto al wrapper en vez de respecto a la ventana, y el velo se pintaba ENCIMA del modal llevandose todos los clics. Parecia un problema de red, y encima en un PC no se reproducia porque tenia las animaciones de Windows desactivadas y `prefers-reduced-motion` lo tapaba. Ya se arreglo en su dia cambiando ese `both` por `backwards` en oleada-b.css. Esta regla es para que no vuelva: los contenedores de pagina no pueden retener el estado final de una animacion, pase lo que pase. `backwards` mantiene la entrada (aplica el primer fotograma antes de empezar) y al terminar devuelve el elemento a su estado propio, sin transform. Comprobado el resto de `both` del programa: `vp-row-enter` acaba en `transform: none` y va en filas de tabla, y `card-enter` va en la tarjeta del login. Ninguno es un contenedor de pagina. */ #main-content, .main-content, .content-wrapper, .parcelas-surface, .terceros-surface, .mano-obra-surface, .legal-hub, .surface-explotaciones, .mv2-content { animation-fill-mode: backwards !important; } /* ======================================================================== 4 · `prefers-reduced-motion`, EN TODO EL PROGRAMA (F13.3) ======================================================================== Lo respetaban 7 hojas de 79. Las otras 72 tenian movimiento y no lo miraban. Con una sola regla global quedan cubiertas todas, incluidas las que se escriban manana. Quien activa esto no pide «menos animacion»: pide que no haya. Puede ser por mareos o por migranas. Asi que se anula, no se acorta a medias. Se usa 1 ms y no 0 s a proposito: con duracion 0 algunos navegadores no disparan los eventos `transitionend`/`animationend`, y hay codigo que espera esos eventos para limpiar clases. Con 1 ms se disparan igual y no se ve nada. */ @media (prefers-reduced-motion: reduce) { *, *::before, *::after { animation-duration: 1ms !important; animation-delay: 0ms !important; animation-iteration-count: 1 !important; transition-duration: 1ms !important; transition-delay: 0ms !important; scroll-behavior: auto !important; } /* NO se pone `animation-fill-mode: none` aqui. Seria lo intuitivo, pero romperia las animaciones de entrada que dependen de `backwards` para no dar un salto, y sobre todo: el bug de los modales tapados se reproducia JUSTO en un PC con esto activado. El seguro es la regla del apartado 3, que vale con y sin `prefers-reduced-motion`. */ } }