sublimated
sign in
Apr 6, 2026 2.3 KB markdown of v8

mermaid

sublimated renders .mmd and .mermaid files as diagrams. push via git, view the rendered diagram on the web.

  • diagrams are rendered server-side on push — no client-side JavaScript needed

  • the rendered SVG is stored alongside the source, so viewing is instant

  • edit mode uses CodeMirror (same as .ts, .py, etc)

  • supported on both sublimated.com (file viewer) and run.sublimated.com (published sites)

  • inline comments and reactions work on the rendered diagram (SVG is inline DOM)

  • demo — example flowchart, push it to see it rendered

supported diagram types

all mermaid.js diagram types work:

  • flowchart / graph

  • sequence diagram

  • class diagram

  • state diagram

  • entity relationship diagram

  • gantt chart

  • pie chart

  • git graph

  • mindmap

  • timeline

  • and more — anything mermaid.js supports

how it works

  1. push a .mmd or .mermaid file via git

  2. sublimated detects the file type and sends it to the mermaid renderer (Selkie, Rust/WASM)

  3. the rendered SVG is stored in CAS as a render_svg representation

  4. when you view the file, the SVG is displayed inline

  5. edit via ~edit opens CodeMirror, save triggers re-render

embedding in markdown

mermaid code blocks in markdown files are also rendered:

```mermaid
graph LR
    A --> B
```

this uses client-side rendering (mermaid.js loaded in the browser). standalone .mmd files use server-side rendering instead.

spike: diagram-aware comments

mermaid SVG nodes get auto-generated IDs (e.g. flowchart-A-0, flowchart-B-1). since we render as inline SVG, these are real DOM elements that already support inline comments and reactions.

open questions for a spike:

  • mermaid IDs are fragile — they change when nodes are reordered. need stable anchors

  • we have Loro CRDTs for collaborative state — could track node positions and stable IDs through edits

  • could extract node labels (text content) as more stable identifiers than auto-generated IDs

  • could map source line ranges to SVG node IDs for comment anchoring (source line 3 = node B = flowchart-B-1)

  • how does this interact with version changes? comments on a node that gets renamed/moved

  • similar problem to typst heading anchors — might share the same anchoring infrastructure