Published timelines need scale, not just scroll

The latest Mermaid work in Notipad Publish started as a visibility bug.

The symptom looked simple: diagrams were scrollable, but the reader could still land on a cropped or over-zoomed view.

The first instinct was to make the container wider and make overflow explicit.

That was necessary.

It was not sufficient.

A public timeline has a different contract from an editor preview:

• it must start at the beginning;
• it must show enough time to be understood before interaction;
• it must make horizontal scroll visible before the reader needs it;
• it must not cut labels at the left or right edge;
• and it must keep the same behavior across Gantt, timeline, flowchart and sequence diagrams.

That is a rendering problem, not a content problem.

The bug was not just clipping

The obvious failure was clipping.

Text appeared outside its container. Bars reached the edge. Some diagrams had scroll, but the scroll affordance was too easy to miss.

The less obvious failure was scale.

A timeline can technically be correct and still be unreadable if the first viewport only shows a narrow slice of the story.

That matters more in a CV or portfolio page than in a dense internal tool. The reader is not debugging a chart. They are trying to understand progression.

When the first view only shows a small part of the years, the diagram feels broken even if the SVG has more content to the right.

So the fix had to answer two questions at once:

1. Can the full diagram still be reached?
2. Does the first viewport already explain enough?

Overflow is a fallback, not the layout strategy

The renderer now treats scroll as an explicit reader control, not as a hidden browser accident.

The important change is the measurement step.

Instead of assuming that every Mermaid SVG will fit the article column, the published page measures the rendered SVG and derives layout variables from the actual result:

• the diagram type;
• the rendered SVG width;
• the content bounds;
• the visible reader area;
• whether a Gantt chart needs a wider time surface;
• and whether labels would be clipped by the initial viewport.

That makes scroll a fallback for wide diagrams, not the main reason the diagram works.

Gantt needed a different rule from other diagrams

The early fix treated every Mermaid block too much like the home-page Gantt.

That was wrong.

A Gantt chart is a time surface. It benefits from a wider canvas because years, tasks and labels compete horizontally.

A sequence diagram or flowchart does not need the same gutter rule.

So the renderer now separates the contracts:

This prevents a fix for one diagram from making every other diagram feel oddly padded.

The first viewport is part of the data visualization

The strongest lesson is that viewport is not decoration.

For a published timeline, the first viewport is part of the visualization.

If the reader can only understand the temporal story after dragging a hidden scrollbar, the published page has failed its first reading pass.

The final rule is therefore stricter:

a public timeline should be scrollable when needed, but it should not require scroll to prove that it is a timeline.

That is why the fix reduced the Gantt base width, reduced the desktop gutter, moved the scroll indicator above the diagram, and normalized section labels after Mermaid renders its internal tspan elements.

The result is not "make the SVG smaller".

It is:

make the diagram readable before interaction, and complete after interaction.

That is the boundary between an editor preview and a published artifact.