Entrevista frontend: ¿Cómo aplicarías mejora progresiva a CSS Masonry?

Planteamiento y contexto

El equipo de producto quiere un muro de imágenes estilo masonry: las tarjetas tienen diferentes alturas, la versión de escritorio usa múltiples columnas, la móvil usa una sola y el contenido debe funcionar para usuarios de teclado y lectores de pantalla. CSS Grid Level 3 está definiendo el diseño masonry, pero la sintaxis y el soporte de los navegadores requieren verificación. Compara el enfoque CSS nativo, columnas y scripts, y diseña un plan de fallback y pruebas.

Qué está evaluando el entrevistador

• Separar el empaquetado visual del DOM, el orden de lectura y el orden de foco.
• Usar detección de características y una matriz de soporte en lugar de suposiciones basadas en el nombre del navegador.
• Manejar dimensiones de imágenes, CLS, número de columnas responsivo, virtualización y costo de reflow.
• Incluir criterios de aceptación para entornos sin script, teclado, lector de pantalla, zoom e impresión.

Preguntas para aclarar primero

1. ¿Las tarjetas deben seguir la hora de publicación y la prioridad, o puede cambiar el orden visual de las columnas?
2. ¿El diseño masonry es decorativo o los usuarios deben leer y operar el contenido en orden?
3. ¿Qué restricciones aplican respecto a navegadores, entornos sin script y SEO?
4. ¿La lista es lo suficientemente grande como para requerir virtualización, paginación o lazy loading?
5. ¿Se requieren funciones de arrastrar y soltar, inserción, alturas dinámicas e impresión?

Estructura de respuesta de 30 segundos

Mantendría fijo el orden semántico del DOM y usaría CSS solo para la mejora visual. Usaría @supports y una matriz de navegadores real para seleccionar masonry donde sea compatible; de lo contrario, recurriría a Grid normal o columnas y aceptaría un espacio en blanco diferente. Reservaría las dimensiones de las imágenes para reducir el cambio de diseño (layout shift) y nunca convertiría a JavaScript en la única vía de accesibilidad. Probaría teclado, lectores de pantalla, zoom, impresión, scripts deshabilitados y listas largas para garantizar un orden de contenido consistente.

Respuesta detallada paso a paso

Paso 1: Definir el balance (trade-off) de masonry

Masonry empaqueta elementos a lo largo de un eje dentro de las pistas del grid mientras ajusta el otro eje. Reduce el espacio vacío y aumenta la densidad visual; no resuelve automáticamente el orden de lectura, el movimiento del foco ni una paginación predecible. Convierte esas restricciones de producto en criterios de aceptación antes de elegir una implementación.

Paso 2: Preservar la semántica y el orden de foco

Renderiza enlaces, botones y encabezados reales en el orden de negocio. No muevas nodos mediante script ni repares el orden visual con un tabindex positivo. Si las columnas visuales difieren del orden del DOM, acéptalo explícitamente o utiliza Grid normal para preservar la lectura fila por fila.

Paso 3: Detectar características y aplicar fallbacks

Coloca la sintaxis experimental detrás de @supports y pruébala en la matriz de destino. Utiliza la sintaxis de masonry soportada por la especificación cuando esté disponible; de lo contrario, recurre a display: grid, pistas fijas o columnas. Mantén el mismo DOM, contenido e interacción en el fallback; solo deben diferir el espacio en blanco y la densidad del empaquetado.

Paso 4: Manejar imágenes y alturas dinámicas

Emite las dimensiones de la imagen o aspect-ratio desde el servidor y combínalos con lazy loading y el object-fit adecuado para reducir el CLS. La carga de imágenes, el intercambio de fuentes y las actualizaciones de contenido provocan reflow, por lo que debes paginar o virtualizar listas largas. Limita la frecuencia de medición por script (throttling) y evita intercalar lecturas y escrituras de diseño que fuercen un diseño sincrónico (synchronous layout).

Paso 5: Evaluar el rendimiento y mantenimiento

Mide el first paint, la tasa de cuadros al hacer scroll, el tiempo de diseño, la memoria y la inserción en listas largas por separado para CSS, columnas y scripts. Documenta la menor diferencia visual y evita duplicar reglas para cada punto de interrupción (breakpoint). Habilita scripts únicamente cuando arrastrar y soltar, animaciones complejas entre columnas o un requisito de compatibilidad heredada explícito realmente lo necesiten.

Paso 6: Cubrir accesibilidad y uso no visual

Navega con el tabulador por cada elemento y verifica que el foco no salte de forma errática. Usa un lector de pantalla para confirmar que los encabezados, enlaces y textos alternativos sigan el orden del DOM. Prueba el zoom al 200%, alto contraste, movimiento reducido, impresión y scripts deshabilitados. Masonry no debe ser la única forma de acceder al contenido.

Paso 7: Publicar y monitorear

Registra la versión de la especificación, la matriz de navegadores y la política de fallback. Monitorea el CLS, LCP, errores de script, desbordamientos (overflow) y la finalización de interacciones con las tarjetas por navegador. Cuando cambie el soporte de la sintaxis, reproduce capturas de pantalla y casos de accesibilidad en un experimento antes de ampliar el despliegue.

Respuesta de muestra de alta calidad

Preservaría el orden semántico del DOM y trataría a masonry como una mejora visual. Usaría @supports y pruebas reales de navegador para la sintaxis de la especificación; recurriría a Grid normal o columnas con el mismo contenido e interacciones como fallback. Reservaría las dimensiones de las imágenes o aspect-ratio para reducir el CLS, y usaría paginación o virtualización en lugar de mediciones sincrónicas frecuentes para listas largas. Las pruebas de teclado, lectores de pantalla, zoom, impresión y entornos sin script deben recuperar el contenido en el orden del DOM. Monitorearía el CLS, los errores de diseño y la finalización de interacciones por navegador, y condicionaría las actualizaciones de especificación a los resultados de reproducción y accesibilidad.

Errores comunes

• Optimizar la densidad visual ignorando el orden del DOM, del foco y de los lectores de pantalla.
• Asumir que todos los navegadores modernos soportan la misma sintaxis de masonry sin @supports y sin pruebas.
• Mover nodos con script o usar tabindex positivo para reparar el orden.
• Omitir dimensiones de imagen y generar CLS y reflow tras la carga.
• Añadir un script siempre activo por compatibilidad sin medir su costo de diseño y memoria.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: ¿Por qué no usar columnas?

Las columnas pueden parecerse a un masonry, pero el contenido se divide por columna y el orden de lectura o de foco puede diferir del orden de negocio. Si el orden importa, es preferible usar Grid normal o aceptar el espacio en blanco.

Pregunta de seguimiento 2: ¿Cómo detectas el soporte para masonry?

Usa @supports y pruebas automatizadas en la matriz de navegadores de destino, registrando las propiedades y valores exactos que pasan la prueba. No infieras el soporte a partir de un User-Agent o una etiqueta de “navegador moderno”.

Pregunta de seguimiento 3: ¿Qué pasa al insertar tarjetas dinámicamente?

Mantén el orden de inserción, reserva las dimensiones de imagen, agrupa las actualizaciones por lotes y evita forzar el diseño elemento por elemento. Las listas grandes necesitan paginación, virtualización y foco restaurable.

Pregunta de seguimiento 4: ¿Cuándo se justifica un fallback mediante script?

Cuando arrastrar y soltar, animaciones complejas entre columnas o un requisito de compatibilidad heredada explícito no puedan satisfacerse con CSS. El script sigue siendo una mejora y el contenido semántico debe seguir disponible si este falla.

Pregunta de seguimiento 5: ¿Cómo demuestras que el diseño visual no rompió la accesibilidad?

Opera cada elemento mediante teclado y lector de pantalla en el orden del DOM, luego prueba zoom al 200%, movimiento reducido, impresión y scripts deshabilitados. Haz que estos resultados sean un requisito obligatorio para el lanzamiento.