Las timelines publicadas necesitan escala, no solo scroll
El último trabajo sobre Mermaid en Notipad Publish empezó como un bug de visibilidad.
El síntoma parecía simple: los diagramas tenían scroll, pero el lector todavía podía llegar a una vista cortada o demasiado ampliada.
La primera respuesta fue ensanchar el contenedor y hacer explícito el overflow.
Eso era necesario.
No era suficiente.
Una timeline pública tiene un contrato distinto al de una preview de editor:
- debe empezar por el principio;
- debe enseñar suficiente tiempo antes de que el lector interactúe;
- debe mostrar el scroll horizontal antes de que haga falta;
- no debe cortar etiquetas en los bordes;
- y debe comportarse de forma coherente entre Gantt, timeline, flowchart y sequence diagrams.
Eso es un problema de render, no de contenido.
El bug no era solo clipping
El fallo evidente era el clipping.
Había texto fuera de su contenedor. Las barras llegaban al borde. Algunos diagramas tenían scroll, pero la pista visual era demasiado fácil de pasar por alto.
El fallo menos evidente era la escala.
Una timeline puede ser técnicamente correcta y aun así no leerse bien si el primer viewport sólo enseña una franja estrecha de la historia.
Eso importa más en un CV o portfolio que en una herramienta interna densa. El lector no está depurando un gráfico. Está intentando entender una evolución.
Si la primera vista sólo enseña una parte pequeña de los años, el diagrama se siente roto aunque el SVG tenga más contenido hacia la derecha.
Así que el arreglo tenía que responder dos preguntas a la vez:
- ¿Se puede alcanzar todo el diagrama?
- ¿La primera vista ya explica lo suficiente?
El overflow es un fallback, no la estrategia de layout
El renderer ahora trata el scroll como un control explícito de lectura, no como un accidente oculto del navegador.
El cambio importante es la medición.
En vez de asumir que cualquier SVG de Mermaid cabrá dentro de la columna del artículo, la página publicada mide el SVG renderizado y deriva variables de layout desde el resultado real:
- el tipo de diagrama;
- el ancho renderizado del SVG;
- los bounds del contenido;
- el área visible del lector;
- si un Gantt necesita una superficie temporal más ancha;
- y si las etiquetas quedarían cortadas en el primer viewport.
Así el scroll queda como fallback para diagramas anchos, no como la razón principal por la que el diagrama funciona.
Gantt necesitaba una regla distinta al resto
El primer arreglo trataba cada bloque Mermaid demasiado parecido al Gantt de la home.
Eso era incorrecto.
Un Gantt es una superficie temporal. Se beneficia de un canvas más ancho porque años, tareas y etiquetas compiten en horizontal.
Un sequence diagram o un flowchart no necesita la misma regla de gutter.
Por eso el renderer separa ahora los contratos:
| Familia de diagrama | Qué necesita |
|---|---|
| Gantt / vistas tipo timeline | Zoom controlado, scroll visible, gutter proporcional y etiquetas de sección estables |
| Flowchart / sequence / otros diagramas | Scroll sólo cuando el contenido supera el viewport, sin heredar espaciado específico de Gantt |
Esto evita que un arreglo para un diagrama haga que todos los demás parezcan extrañamente acolchados.
El primer viewport también forma parte de la visualización
La lección fuerte es que el viewport no es decoración.
En una timeline publicada, el primer viewport forma parte de la visualización.
Si el lector sólo entiende la historia temporal después de arrastrar una barra de scroll escondida, la página publicada falla en la primera lectura.
La regla final queda más estricta:
una timeline pública debe poder scrollearse cuando haga falta, pero no debería necesitar scroll para demostrar que es una timeline.
Por eso el arreglo redujo el ancho base del Gantt, redujo el gutter en escritorio, movió el indicador de scroll encima del diagrama y normalizó las etiquetas de sección después de que Mermaid renderice sus tspan internos.
El resultado no es "hacer el SVG más pequeño".
Es:
hacer que el diagrama sea legible antes de interactuar, y completo después de interactuar.
Esa es la frontera entre una preview de editor y un artefacto publicado.