Los errores que ya no deberías cometer y hacia dónde va esto
El catálogo de quince errores con su síntoma y su corrección, qué está llegando a la plataforma y en qué estado real, y cómo escribir hoy el movimiento que se podrá borrar mañana.
El cierre del track no es un resumen. Es la lista de cosas que, después de cuarenta y dos niveles, ya no tienen excusa: quince errores concretos con su síntoma, su causa y su corrección, en el orden en que aparecen en una base de código real. Y después, una mirada honesta a lo que viene, separando lo que ya puedes usar de lo que todavía es una promesa.
- Reconocer los quince errores por su síntoma y aplicar la corrección correspondiente.
- Distinguir lo que ya está disponible de lo que aún no lo está en los cuatro motores.
- Anticipar qué trabajo tuyo va a absorber la plataforma en los próximos años.
- Escribir el movimiento de forma que se pueda borrar cuando eso ocurra.
Los quince errores
Uno. Animar width, height, top, left o margin. Síntoma: la animación se congela en cuanto pasa cualquier otra cosa. Corrección: transform con contra-escala, grid-template-rows, o interpolate-size donde exista. Si de verdad no hay alternativa, mídelo y acótalo con contain.
Dos. transition: all. Síntoma: propiedades que se animan sin que nadie lo pidiera, y coste en cada cambio de estado. Corrección: lista explícita de propiedades. Es la regla de lint que más devuelve.
Tres. will-change permanente en una hoja de estilos. Síntoma: la memoria de vídeo crece y no baja; la página se hunde en móvil. Corrección: pedirlo al empezar la interacción y soltarlo al terminar.
Cuatro. translateZ(0) como remedio universal. Síntoma: el mismo que el anterior, más composición implícita en cascada. Corrección: promocionar el contenedor que se mueve, no cada hijo.
Cinco. Ignorar la interrupción. Síntoma: pulsar dos veces rápido deja el elemento a medio camino, invisible o duplicado. Corrección: una máquina de estados explícita, con el estado en un atributo que el navegador entienda y la animación colgando de él.
Seis. ease-in-out para todo. Síntoma: las entradas se sienten lentas y las salidas se resisten a irse. Corrección: el catálogo de cuatro curvas por rol.
Siete. Escalonar sin tope. Síntoma: una lista de veinte elementos tarda casi un segundo en aparecer entera. Corrección: paso de cuarenta milisegundos, máximo seis elementos escalonados, trescientos milisegundos totales.
Ocho. Ocultar con opacity: 0 para revelar después. Síntoma: el tabulador se va a contenido invisible; el lector de pantalla anuncia lo que aún no aparece. Corrección: la ocultación la pone JavaScript y se retira al terminar; sin JavaScript, el contenido está visible.
Nueve. Apagar el movimiento en lugar de reducirlo. Síntoma: con la preferencia activada la interfaz salta y se pierde información. Corrección: la tabla de sustituciones y el multiplicador de distancia.
Diez. Cargar un motor completo para un indicador de carga. Síntoma: decenas de kilobytes en la ruta crítica para un arco que gira. Corrección: cuatro líneas de CSS que corren en el compositor.
Once. Medir en la máquina de desarrollo. Síntoma: “en mi portátil va perfecto”. Corrección: estrangulamiento de CPU a 4x como mínimo, y un dispositivo real de gama media antes de dar nada por bueno.
Doce. No limpiar al desmontar. Síntoma: animaciones sobre nodos desconectados, observadores vivos, memoria que crece. Corrección: cancelar en el desmontaje, y comprobarlo con el inventario de getAnimations().
Trece. Elegir la duración por gusto. Síntoma: veinte valores distintos entre 150 y 400 milisegundos sin ningún patrón. Corrección: la escala, y las tablas de distancia y de frecuencia.
Catorce. Lottie para lo que no lo necesita. Síntoma: un intérprete completo en el hilo principal para una animación de doce formas. Corrección: el árbol de alternativas; SVG animado, sprites o vídeo con alfa cubren casi todo.
Quince. Confiar en la demo. Síntoma: se ve genial en la revisión y va mal en producción. Corrección: el destello de repintado, el bloqueo del hilo, el panel de capas y el perfil con estrangulamiento. Todo eso son minutos.
Si tuvieras que auditar un producto ajeno en una hora, busca transition: all, busca will-change en las hojas de estilo, busca width y height en listas de propiedades animadas, ejecuta el inventario de animaciones y bloquea el hilo principal durante una interacción. Con eso encuentras casi todo lo que hay que encontrar.
Lo que ya puedes usar y lo que no
El estado real de las piezas modernas, sin optimismo:
Disponible en los cuatro motores. Las transiciones y las animaciones CSS con todo su modelo. WAAPI completa, incluidas getAnimations, commitStyles y la composición. @starting-style y transition-behavior: allow-discrete, que juntas resuelven la entrada y la salida de elementos que aparecen y desaparecen. linear() para aproximar muelles. Las transiciones de vista del mismo documento, que son Baseline desde 2025. El posicionamiento por anclaje, que entró en Baseline cuando Firefox lo implementó a principios de 2026, aunque @position-try requiere una versión reciente de Safari.
Todavía no universal. Las animaciones dirigidas por scroll son la ausencia más notable: Chromium y Safari las tienen, Firefox no las ha implementado, así que cualquier uso serio necesita @supports (animation-timeline: scroll()) y un retroceso. Las transiciones de vista entre documentos están llegando durante 2026 y aún no se pueden dar por hechas. interpolate-size con allow-keywords resuelve por fin la animación a auto y no está en todas partes. prefers-reduced-transparency no es Baseline.
La regla para todos estos casos es la misma y es la que hace que el código envejezca bien: la ausencia de la función tiene que ser un resultado aceptable, no un fallo. Sin timeline de scroll, el contenido está visible. Sin transición de vista, la navegación ocurre igual. Sin interpolate-size, la rejilla de una fila hace el trabajo. Ninguna de las tres es una degradación que alguien vaya a notar.
Hacia dónde va
Cuatro tendencias, con lo que implican para tus decisiones de hoy.
La plataforma absorbe lo que hacían las librerías, y lo hace por el lado declarativo. El patrón se repite: primero se resolvía con JavaScript midiendo cajas, después apareció una propiedad CSS que lo declaraba, y el JavaScript se borró. Pasó con las transiciones, con los keyframes, con el revelado al hacer scroll, con la altura automática y con la transición entre pantallas. Lo que sigue en esa cola es previsible: más propiedades animables fuera del hilo principal y más formas de declarar el estado anterior de algo que todavía no existe. El trabajo de captura que ahora es tuyo es el candidato natural a desaparecer.
El compositor gana terreno. La dirección es que más trabajo salga del hilo principal, y ya se ve en cómo se han diseñado las timelines de scroll: están pensadas para poder ejecutarse sin JavaScript precisamente porque así pueden vivir fuera del hilo principal. Cualquier API nueva de animación que se proponga va a tener esa restricción como criterio de diseño.
El movimiento entra en el sistema de diseño. Con veinte años de retraso respecto al color y a la tipografía, pero entra: tokens de duración y de curva en las herramientas de diseño, generación a CSS y a JavaScript desde una fuente única, reglas de lint que impiden los valores sueltos. Dentro de unos años discutir una duración concreta en una revisión será tan raro como discutir hoy si un margen debe ser de veintidós o de veinticuatro píxeles.
La accesibilidad del movimiento deja de ser opcional. El criterio de movimientos de arrastre ya es nivel AA. La dirección normativa es clara y cada revisión de las pautas añade requisitos en esta zona. Y como la mayoría de lo que hace daño es también lo que más cuesta ejecutar, el trabajo se paga solo.
Lo que no va a cambiar merece decirse, porque es donde conviene invertir el aprendizaje: la fisiología del sistema vestibular, el umbral de causalidad de los cien milisegundos, la ley de Weber que obliga a que las escalas sean geométricas, el hecho de que la atención sea indivisible, y que rellenar píxeles cueste proporcionalmente al área. Ninguna versión de ningún navegador va a modificar esas cinco cosas, y son las que te permiten decidir bien sobre una API que todavía no existe.
Hay una tentación natural al terminar cuarenta y tres niveles sobre animación, y es querer usarlo todo. Es exactamente la conclusión contraria a la que llevan los datos. Si repasas el mapa de patrones, la mayoría de lo que una interfaz necesita se resuelve con CSS puro; si repasas los quince errores, casi todos consisten en haber hecho algo de más; si repasas el nivel de accesibilidad, el ejercicio de apagar el movimiento revela que buena parte de las animaciones de cualquier producto no estaban comunicando nada; y si repasas el de rendimiento, el trabajo más barato es siempre el que no se hace. La progresión natural de alguien que domina esto no es hacia más movimiento, sino hacia menos movimiento mejor elegido, ejecutado con la herramienta más simple que lo resuelva y sostenido por un sistema que no depende de que esa persona siga en el equipo. El nivel de dominio no se demuestra montando una secuencia de cuarenta pasos con scroll y texto dividido: se demuestra sabiendo que ese producto no necesitaba ninguna de las dos cosas, y siendo capaz de defenderlo con la frecuencia de uso, el presupuesto de fotograma y el perfil en un dispositivo real en lugar de con una opinión. Y hay un último matiz que evita que esto suene a puritanismo, porque no lo es. Toda esta disciplina —el rigor sobre las propiedades, sobre el presupuesto, sobre los umbrales vestibulares, sobre los tokens— no existe para eliminar el movimiento del producto. Existe para que, cuando algo de verdad merezca moverse, puedas permitírtelo: puedas gastar seiscientos milisegundos y una coreografía cuidada en el momento que lo justifica, porque las otras cincuenta pantallas no están malgastando el presupuesto en escalonados que nadie mira ni mareando a nadie con un paralaje. El movimiento bien administrado no es movimiento ausente: es movimiento que se nota porque es escaso, y que se puede permitir ser generoso justo donde importa.