Published pages need a content-aware runtime

Yesterday's work looked like a collection of small fixes across Notipad Publish, the renderer, and Nikki's public site.

A timeline with a different color.

One less title on the home page.

A flowchart that stops clipping.

A code block that gets its language back.

Seen separately, that looks like polish.

Seen together, a different decision appears:

a published page can no longer treat every block as if it needed the same runtime.

The problem was not only visual

The public site now mixes several surfaces in a single reading flow:

That changes the question.

It was no longer “how do we fit more runtime into the published page”.

It became:

how do we make each page load only the capability it actually needs in order to stay readable?

A fixed bundle stopped being a serious answer

When publishing was more homogeneous, loading the same package for every page was an easy answer.

But that convenience started breaking two things at once.

The first was the system's mental shape: if every page inherits Mermaid, syntax highlighting, and layout rules even when it does not use them, publishing stops being precise composition and turns into a generic blanket.

The second was reading quality: a flowchart does not need the same contract as a Gantt chart, and a json block without a language class leaves the public renderer without enough context to decide how it should be painted.

The real decision was to move from a fixed runtime to a content-conditioned one:

• if the page has no diagrams, it does not load Mermaid;
• if the markdown contains no highlightable code, it does not load the highlighter;
• if the diagram is a flowchart, it gets sizing rules that differ from a timeline;
• and if a block is not highlighted, it still keeps the information about which language it was.

That is not premature optimization.

It is a better contract between content and public reading.

The contract had to survive the whole chain

The interesting part was not inside one repo.

The change crossed the rendering core, the markdown rendering service, and the page publishing service.

That matters because a published page fails when one layer assumes another will somehow “figure it out”.

The chain became more explicit:

1. The base renderer keeps the language class even when it does not apply highlighting.
2. The render service only loads the highlighter when it detects that the markdown actually needs it.
3. The publish service only injects the Mermaid runtime when the page contains diagrams.

The lesson is simple:

if content meaning gets lost in an intermediate stage, the public runtime ends up compensating with more fragile heuristics.

Content also started dictating the rules

Nikki's home page stopped repeating the name as a large title and started differentiating education visually inside the timeline.

That can look editorial, but it confirms the same movement.

Once publishing matures, content stops being designed to survive a blunt renderer and starts relying on a more specific one.

The page no longer needs a redundant heading just in case.

The timeline no longer needs to pretend that every bar means the same thing.

Presentation can become more precise because the public runtime is more precise too.

Publishing is no longer exporting context-free HTML

The strongest idea from the day is this:

a published page is not a static dump from the editor.

It is a composition of capabilities.

Some pages need diagrams.

Some need highlighting.

Some only need typography, hierarchy, and silence.

The right runtime is not the biggest one.

It is the smallest one that still preserves the meaning of the content.

That is where publishing stops being “serve markdown” and starts feeling like designing a real public reading surface.

Part of my product and platform notes. Follow the blog or contact me.