File Preview Inline

El usuario debe poder evaluar el contenido de un archivo antes de comprometerse a descargarlo. Forzar una descarga solo para ver si el archivo es relevante destruye el flujo y genera fricción innecesaria. La previsualización inline aplica el principio de progressive disclosure: mostrar primero lo esencial y dejar la acción secundaria (descarga) disponible pero subordinada. Es el patrón estandar de Google Drive, Dropbox y Slack, donde el preview abre en panel o modal y el botón de descarga vive en el toolbar, no como CTA forzado.

El navegador decide como procesar un recurso usando el MIME type del header Content-Type, no la extensión del archivo. Enviar el MIME correcto es el prerequisito técnico para que el preview funcione: imagenes (image/*) con <img>, PDF (application/pdf) con <iframe> o <embed> y Content-Disposition: inline, video con <video>, código con un bloque <pre><code> y syntax highlighting. application/octet-stream fuerza al navegador a tratar el archivo como binario desconocido y proponer "Guardar como": evitarlo para archivos que deben renderizarse inline.

Ningun sistema soporta todos los formatos. Cuando no es posible renderizar un preview (.psd sin soporte, .dwg, .bin, archivos cifrados), el usuario aún necesita contexto suficiente para decidir si descarga. El estado vacio no debe ser un mensaje critico de error, sino un estado informativo: icono representativo del tipo, nombre completo del archivo, tamaño legible, tipo MIME en lenguaje claro, fecha de modificación y un botón de descarga como CTA primario. Es exactamente el patrón que usa Google Drive para tipos no soportados.

Los archivos pesados (PDF multi-página, video, imagenes de alta resolución) tienen latencia real. El patrón correcto separa la carga en dos fases: primero el placeholder de baja calidad (LQIP o poster del video) y luego el recurso completo. Esto da feedback visual inmediato y reduce la percepción de espera. Para video, el atributo poster en <video> muestra una imagen estática hasta que el usuario pulsa play; para imagenes, LQIP o JPEG progresivo presentan contenido borroso que se enfoca. Nunca dejes un spinner vacio: el usuario asume que fallo y cierra.

El preview inline no es el destino final, es una etapa intermedia: el usuario que termino de evaluar el archivo necesita actuar sobre el. Las acciones mínimas son descargar el original, abrir en app externa (si aplica) y copiar enlace o compartir. Deben vivir en un toolbar siempre visible, no escondidas en un menú de tres puntos que exige descubrimiento. El orden convencional, establecido por Dropbox, Google Drive y Figma, ubica la navegación a la izquierda, el nombre al centro y las acciones primarias más el botón de cerrar a la derecha.

Cuando el usuario explora multiples archivos de una carpeta o los adjuntos de un mensaje, cerrar y reabrir el preview por cada uno destruye el flujo. La navegación en contexto (flechas en el modal, teclas izquierda/derecha) es el patrón estandar de Finder, Google Drive y Slack. Debe incluir un indicador de posición ("3 de 12") y soporte completo de teclado: WCAG 2.1.1 Keyboard (nivel A) exige que toda la funcionalidad, incluida la navegación entre items de la galeria, sea operable con teclado, no solo al hacer hover con el raton.

El modal de preview debe atrapar el foco al abrirse y restaurarlo al elemento que lo activo al cerrarse. Las imagenes requieren alt descriptivo y los PDF embebidos deben tener capa de texto (tags): un PDF escaneado sin tags es solo una imagen y no es accesible para lectores de pantalla. La tecla Escape cierra el modal y todos los controles del toolbar deben alcanzarse con Tab. WebAIM es explicito: un PDF sin etiquetar no se considera accesible. La capa de tags es el requisito base, no una mejora opcional.

Una lista de 20 adjuntos con preview automático puede descargar cientos de MB que el usuario nunca ve. El atributo nativo loading="lazy" en <img> e <iframe> delega al navegador cuando cargar; para casos no cubiertos (poster de video, preloaders de PDF) Intersection Observer es la solución moderna: asincrona, sin scroll events, sin bloquear el hilo principal. Para embeds de terceros (YouTube, Vimeo) la técnica "facade" reemplaza el iframe por un thumbnail estático hasta el clic. web.dev cuantifica el ahorro de la facade: más de 500 KiB en la carga inicial de un embed de YouTube; si el usuario nunca reproduce, esos recursos no se descargan jamas.