Zachary F. Mainen · HAAK · Methods 50 · March 2026

Web-Native Figures

A paper produces two distinct figure sets with different jobs. Paper figures are raster exports — high-resolution PNGs for LaTeX, arXiv, and print. Web figures are inline SVGs — compact, dark-themed,…

#Why This Method Exists

A paper produces two distinct figure sets with different jobs. Paper figures are raster exports — high-resolution PNGs for LaTeX, arXiv, and print. Web figures are inline SVGs — compact, dark-themed, accessible without any external dependency. The mistake is treating them as the same artifact at different resolutions. They are different things: the paper figure proves; the web figure communicates. A paper figure can be dense because the reader is committed. A web figure has one shot at a skimming visitor.

The Library Theorem paper produced three diverging versions of its figures — paper PDFs, web landing page SVGs, and a separate set for the arXiv submission tarball. None stayed synchronized. This method establishes the structure that prevents that sprawl.

#The Two Figure Types

Paper figures (fig<N>_<slug>.png):

  • Format: PNG, minimum 300 DPI
  • Color: publication white background, standard matplotlib/seaborn defaults or lab palette
  • Source: data pipeline scripts in 06-release/figures/
  • Consumer: LaTeX (\includegraphics), arXiv tarball, PDF compiler
  • Rule: one figure per claim; captions live in the LaTeX source, not baked into the image

Web figures (descriptive name, inline SVG):

  • Format: SVG, embedded directly in HTML — no <img src="...">, no external file reference
  • Theme: dark background #1a1a1a, primary teal #2E9696, secondary cream #DFE6E4, font IBM Plex Mono
  • Consumer: landing page at web/papers/<slug>/index.html
  • Rule: one story per figure; titles and annotations are part of the SVG

The two types share no files. Attempting to share them (e.g., converting a paper PNG to SVG for the web, or using a web SVG in LaTeX) always fails — the aesthetics, density, and background assumptions are incompatible.

#Design Tokens for Web Figures

Every web figure follows this token set without exception. Deviation creates inconsistency across the landing page.

Background:    #1a1a1a   (figure canvas)
Page bg:       #0f0f0f   (surrounding page)
Primary:       #2E9696   (teal — data lines, key annotations, highlights)
Secondary:     #DFE6E4   (cream — axis labels, body text, secondary lines)
Muted:         #4a4a4a   (gridlines, borders, inactive elements)
Font:          IBM Plex Mono, monospace fallback
Font sizes:    title 14px, labels 11px, annotations 10px
Stroke widths: data lines 2px, axes 1px, gridlines 0.5px

Do not introduce new colors for a single figure. If a figure requires a third data series color, use opacity variants of teal (#2E9696 at 60%, 30%) before introducing a new hue.

#The "One Story" Principle

Each web figure carries exactly one claim. The title states the claim in plain language — not a description of what is plotted, but what the reader should conclude.

Bad title: "Accuracy vs. training steps across conditions" Good title: "Structured input closes the gap in 3k steps"

Simplification checklist before finalizing a web SVG:

  • Remove the legend if the figure has one data series or if annotations are clearer
  • Remove gridlines unless they are load-bearing for reading values
  • Remove axis ticks that don't correspond to meaningful thresholds
  • Annotate directly on the data, not in a separate legend
  • Cut any panel that doesn't support the title claim

A web figure that needs a legend and a caption to make its point belongs in the paper, not the landing page.

#Inline SVG Embedding

Web figures are embedded directly in the HTML — no external file, no JavaScript, no CDN dependency. The entire figure is self-contained in the page source.

<figure class="haak-figure">
  <svg viewBox="0 0 600 300" xmlns="http://www.w3.org/2000/svg"
       style="width:100%;max-width:600px;background:#1a1a1a;">
    <!-- figure content -->
    <text x="300" y="24" text-anchor="middle"
          font-family="IBM Plex Mono,monospace" font-size="14"
          fill="#DFE6E4">Structured input closes the gap in 3k steps</text>
    <!-- axes, data, annotations -->
  </svg>
  <figcaption>Brief elaboration if needed — one sentence max.</figcaption>
</figure>

Properties this enforces:

  • No external dependencies. The page works offline, in print, in any environment.
  • No CORS issues. No <img> tag fetching from a separate origin.
  • Responsive by default. viewBox + width:100% scales correctly without media queries.
  • Inspectable. Anyone reading the page source sees the figure data directly.

#Standard Figure Set for a Paper Landing Page

A landing page is not a paper summary. It covers the key findings — typically three to five — in figures that stand alone without reading the paper. The standard set:

  1. Hook figure — the central result, simplified to one panel. The clearest evidence for the main claim.
  2. Method figure — the setup or approach, enough for a reader to understand what was measured or built. Often a schematic rather than a data plot.
  3. Supporting result — a secondary finding that either validates the method or extends the main claim.

Optional (add only if the paper's contribution requires it):

  1. Comparison figure — where the approach sits relative to prior work or baselines.
  2. Failure/boundary figure — where the method breaks down. Builds credibility.

Do not create a web figure for every paper figure. Choose the three to five that tell the story. The rest stay in the paper.

#Directory Map

projects/<domain>/<paper>/
├── 06-release/
│   ├── figures/                  # paper PNGs — fig1_<slug>.png, fig2_<slug>.png ...
│   ├── arxiv-submission/         # tarball contents: .tex, .bbl, figures/
│   │   └── figures/              # copies of paper PNGs for arXiv
│   └── <paper>-YYYY-MM-DD.pdf    # compiled paper PDF

web/papers/<slug>/
└── index.html                    # landing page with inline SVGs

web/ttt/                          # exception: TTT has its own web dir (predates this method)

The landing page lives in web/papers/<slug>/, not alongside the paper source. The web and paper trees are intentionally separate — they have different owners (Herald/Designer vs. Compositor) and different update cycles.

#Naming Conventions

Paper figures:

fig1_main-result.png
fig2_method-diagram.png
fig3_ablation.png

Zero-padded numbering only when the paper has 10+ figures. The slug matches the caption label in the paper (Figure 1: Main result).

Web SVGs: SVGs are inline — they don't have filenames. But the <figure> element should carry a data-figure attribute for scripting and accessibility:

<figure class="haak-figure" data-figure="main-result">

Landing page: Always index.html — never landing.html, paper.html, or the paper title. The URL should be haak.world/papers/<slug>/.

#Keeping Versions in Sync

Three artifacts can drift: the paper PDF, the arXiv submission, and the landing page. The canonical source of truth for each:

ArtifactCanonical sourceUpdate trigger
Paper PDF06-release/<paper>.pdfAny revision to .tex source
arXiv tarball06-release/arxiv-submission/Each arXiv submission version
Landing pageweb/papers/<slug>/index.htmlMajor revision or new finding

The landing page is not automatically updated when the paper changes. It is a curated artifact — update it intentionally, not mechanically. When a figure changes substantially in the paper, review whether the corresponding web SVG needs updating. A minor axis range change in the paper figure does not require an SVG revision. A qualitatively different result does.

Sync checklist on paper revision:

  1. Did any figure caption label change? Update data-figure attributes.
  2. Did any key claim change? Revise the corresponding SVG title.
  3. Did a figure get added or removed? Update the figure set on the landing page.
  4. Did the abstract change? Update the landing page opening text.

The arXiv submission and the PDF stay synchronized automatically because both compile from the same LaTeX source. The landing page diverges by design — it is the accessible, curated face, not a mirror.

#Governance: Who Owns What

ArtifactOwner roleCan edit without review
Paper figures (PNG)CompositorYes — within paper revision workflow
Web SVGs (inline)DesignerYes — within landing page updates
Landing page structureDesigner + HeraldStructural changes need Herald sign-off
arXiv tarballCompositor + LiaisonLiaison approves before submission

When a figure changes in both the paper and the web (a claim revision), both Compositor and Designer must act. Neither owns the change alone. The Herald post announcing the revision is the coordination point — it names both updates.

haak method — 50 — web-native figures — 2026-03-19 — designed after Library Theorem paper sprawl. Paper figures prove. Web figures communicate. Keep the trees separate, update the landing page intentionally, never share files between the two.

Methods 50 — Web-Native Figures — 2026 — Zachary F. Mainen / HAAK