scroll-behavior y la preferencia de movimiento reducido

scroll-behavior: smooth es una de las declaraciones más satisfactorias de escribir y una de las que más daño hace cuando se escribe mal. Convierte cada salto de scroll en una animación, incluidos los que el usuario no pidió, y para una parte de la población el desplazamiento animado no es un detalle estético: provoca mareo. La declaración correcta ocupa cuatro líneas en vez de una, y la diferencia importa.

Qué afecta y qué no

scroll-behavior se declara en un contenedor de scroll —incluido el elemento raíz— y define cómo se realizan los desplazamientos provocados por la navegación o por la API, no los del usuario.

html { scroll-behavior: smooth; }

Afecta a:

• La navegación a un fragmento, es decir, pulsar un enlace #seccion.
• element.scrollIntoView() sin argumentos.
• window.scrollTo(), scrollBy() y element.scroll() cuando no especifican behavior.
• El desplazamiento al restaurar la posición al volver atrás en el historial.
• El desplazamiento por teclado en algunos motores.

No afecta al desplazamiento con la rueda del ratón, el trackpad ni el gesto táctil. Esos los controla el sistema operativo y el navegador, y CSS no los toca.

Las APIs aceptan un behavior explícito que gana sobre la declaración CSS:

elemento.scrollIntoView({ behavior: 'smooth', block: 'start' });
window.scrollTo({ top: 0, behavior: 'instant' });   // fuerza el salto seco

Los tres valores de behavior en la API son auto —usa lo que diga el CSS—, smooth y instant. En CSS, los valores de la propiedad son auto y smooth; no existe instant como valor de la propiedad.

La preferencia de movimiento reducido

prefers-reduced-motion: reduce es la señal que el usuario emite desde los ajustes del sistema. En macOS es “Reducir movimiento”, en Windows “Mostrar animaciones”, en Android e iOS opciones equivalentes. Quien la activa suele tener un motivo médico: trastornos vestibulares, migraña con aura, epilepsia fotosensible.

Un desplazamiento suave de una página entera es, en términos de estímulo visual, uno de los movimientos más agresivos que produce una interfaz: toda la superficie de la pantalla se mueve durante varias décimas de segundo. Es exactamente el tipo de movimiento que la preferencia pide evitar.

La declaración correcta invierte el orden por defecto:

/* por defecto, sin animación */
html { scroll-behavior: auto; }

/* suave solo si el usuario no ha pedido lo contrario */
@media (prefers-reduced-motion: no-preference) {
  html { scroll-behavior: smooth; }
}

Fíjate en que la consulta es no-preference y no reduce. La diferencia es importante: escribir el suave por defecto y anularlo con reduce deja sin proteger a los navegadores y sistemas que no exponen la preferencia, porque en ellos la consulta reduce no casa y el suave se queda aplicado. Con no-preference, el caso indeterminado cae del lado seguro.

En JavaScript, la comprobación equivalente:

const suave = window.matchMedia('(prefers-reduced-motion: no-preference)').matches;
elemento.scrollIntoView({ behavior: suave ? 'smooth' : 'instant', block: 'start' });

flowchart TB
A[Vas a declarar desplazamiento suave] --> B[Declara auto por defecto]
B --> C[Envuelve el smooth en prefers-reduced-motion no-preference]
C --> D{Tambien lo haces desde JavaScript}
D -->|Si| E[Consulta matchMedia y pasa instant cuando corresponda]
D -->|No| F[Listo]
A --> G[Nunca declares smooth sin condicion]
G --> H[El caso indeterminado quedaria sin proteger]
style A fill:#89b4fa,color:#11111b
style C fill:#a6e3a1,color:#11111b
style E fill:#a6e3a1,color:#11111b
style G fill:#f38ba8,color:#11111b
style H fill:#f38ba8,color:#11111b

Los detalles que se notan

La duración no se controla. No hay ninguna propiedad para ajustar cuánto dura el desplazamiento suave ni con qué curva. Cada motor usa su propia función, que además suele depender de la distancia. Si el diseño exige una duración concreta, hay que animar la posición a mano con requestAnimationFrame o con la API de animaciones, y en ese caso hay que reimplementar también la interrupción por gesto del usuario, que el nativo hace bien y una implementación manual casi nunca.

Se interrumpe. Un desplazamiento suave en curso se cancela en cuanto el usuario hace scroll manualmente. Es el comportamiento correcto y una de las cosas que más cuesta reproducir a mano.

Se combina con el ajuste. Si el contenedor tiene scroll-snap-type, el desplazamiento suave acaba en un punto de ajuste. Las dos características se coordinan sin que tengas que hacer nada.

Interactúa con la cabecera fija. La navegación a un fragmento coloca el destino en el borde superior del scrollport, que puede estar debajo de una cabecera pegajosa. La corrección no es tocar scroll-behavior, es scroll-padding-block-start en el contenedor de scroll, que trata la última lección de este nivel.

html {
  scroll-padding-block-start: 4.5rem;   /* la altura de la cabecera */
}

Cuidado con declararlo en html y en body a la vez. Solo uno de los dos es el contenedor de scroll del documento, y cuál lo sea depende del modo de renderizado. Declararlo en html es lo correcto; añadirlo también en body no ayuda y puede confundir al leer el código.