fix(export): render math, highlighting and diagrams into the exported HTML

[PathGao]

6 / 6 of the stack. Base: #409.

The defect

exportAsHtml re-renders from raw Markdown and never calls renderRichContent, which only ever ran in the viewer. An exported file therefore carried:

<p data-math="display" data-math-source="E = mc^2">E = mc^2</p>
<pre><code class="language-mermaid">graph TD; …</code></pre>

— LaTeX source, colourless code, and diagrams as source blocks. The person you exported the document for saw none of it rendered.

This is the last instance of the audit's "two paths do the same thing and only one is maintained".

The fix: one function, two callers

renderRichContent moves out of MarkdownViewer.svelte into src/lib/utils/richContent.ts, taking { root, libraries, mermaidTheme, … } instead of closing over component state, and reading root.ownerDocument rather than the global — so a detached element is a first-class caller. The export renders into the wrapper it already built. No offscreen container, no second document, no iframe.

The viewer keeps an 8-line wrapper supplying the live element and the clipboard behaviour. sanitizeDiagramSvg moves alongside — it is the diagram policy, and it belongs next to the only thing that makes diagrams. sanitize.ts is untouched.

Library loading moves in too, as loadRichContentLibraries() behind a module-cached promise, so the export can never get a differently configured KaTeX or a different highlight.js language registry than the preview.

Sanitization: the document filter is not re-run

Pipeline: render_markdown → sanitizeMarkdownHtml → processMarkdownHtml → renderRichContent → href/image passes.

The document policy still sees the untrusted document, and only that. Everything after is produced by our own libraries from already-filtered text: highlight.js re-emits the block as escaped text, KaTeX builds nodes itself and runs with its default trust: false (so \href, \url, \includegraphics are inert), and mermaid's SVG goes through sanitizeDiagramSvg — the same filter the preview uses.

Re-running MARKDOWN_SANITIZE_CONFIG afterwards would also destroy every diagram (FORBID_TAGS: ['style']). Both reasons point the same way. exportSanitize.test.ts's ordering assertions hold unchanged.

Mermaid's <style> in an exported file

Read from mermaid 11.16.0's source rather than assumed:

1. It is namespaced. createUserStyles → compileCSS(svgId, …) runs stylis with an addNamespace middleware prefixing every rule with #<svgId>, and deletes any at-rule outside a small allowlist — @import and @font-face are removed with a warning. The id is one Markpad generates. The block cannot restyle anything outside its diagram, and cannot pull in a remote stylesheet or font.
2. It is not a new capability. sanitizeCss only checks brace balance, so a hostile classDef could land a url(https://…) in it — but the export already leaves remote <img src="https://…"> exactly as the author wrote it, which is what that CSP clause is for. A document that wants to beacon on open can do it in one line of Markdown with no diagram involved.
3. The export is the less privileged place for it. The identical <style> has been entering the app's live document since diagrams were added. There it is worth forbidding at the document level — it can hide the title bar. In a standalone file whose entire content is the author's own document, there is nothing to hide.

The reasoning is written into the doc comment where the next person will hit it.

KaTeX fonts: #382's conclusion reverses, because its premise did

#382 declined to embed them on the measured grounds that there was no KaTeX output in an export. That is exactly what this PR changes, so the question was re-measured rather than inherited.

The failure is not missing glyphs — it is wrong ones that look right:

input	KaTeX emits	without the font, the reader sees
\mathbb{R}	ASCII R + class mathbb → KaTeX_AMS	R, not ℝ
\mathcal{L}	ASCII L + mathcal → KaTeX_Caligraphic	plain L
\mathfrak{g}	ASCII g + mathfrak → KaTeX_Fraktur	plain g
\left(…\right)	( + delimsizing size3	normal-height paren around a two-line fraction
\sum	U+2211 + op-symbol large-op	undersized serif operator

Measured end to end through the real exportAsHtml:

document	before	after
no math	72,977 B	68,213 B (−6.5%)
simple algebra	73,010 B	230,471 B
calculus (∑ ∫ big delims)	72,983 B	242,431 B
analysis (ℝ ℋ 𝔤)	72,985 B	315,312 B

Only referenced families are embedded — all 20 faces would be 338 KB on every export. Granularity is the family, not the face, deliberately: face-level would cut simple algebra to ~57 KB but requires resolving the cascade (\mathbf adds weight to a family; **$x$** inherits it), and getting that subtly wrong renders one variable in Times with nothing looking broken. "If a family is referenced, ship its faces" cannot fail that way.

No CSP change needed — font-src data: was already in EXPORT_CSP.

A bug that would have made this a silent no-op

The build emits KaTeX's font URLs relative to the stylesheet (url(./KaTeX_Main-Regular.B22Nviop.woff2) inside _app/immutable/assets/*.css, verified against a real npm run build), not relative to the page. Resolving them against location.href 404s the face, the face is dropped, and the formula quietly falls back to a serif — nothing looks broken. They are absolutised during the document.styleSheets walk, while the owning sheet is still in hand.

Preview-side changes, all narrowing

• Library loading is now atomic. Previously hljs was assigned after the first Promise.all and mermaid/renderMathInElement after a second await, leaving a window where hljs was truthy and the render guard was not.
• hljs.highlightElement is wrapped in try/catch — one bad block no longer aborts the rest of the render, or the rest of an export.
• Mermaid ids gained the loop index. They were mermaid-${Date.now()}-${rand}; two diagrams in the same millisecond could collide, and that id namespaces the diagram's own <style> and its marker URLs.

Otherwise the extracted function is byte-for-byte the old logic.

Tests

scripts/exportRichContent.test.ts drives the real exportAsHtml and asserts on the bytes handed to save_file_content — the full path including the dialog, the renderer round trip, the sanitize/process pipeline, the font pass and buildExportDocument.

Baseline	469 / 0
Final	478 / 0
Counter-proof — modules present, the two calls deleted from export.ts	5 pass / 4 fail

The four that go red are exactly the four artefact assertions: typeset math, highlighted code, drawn diagrams, embedded fonts.

Two things are stood in for, both at a library boundary rather than one of ours: highlight.js / KaTeX / mermaid (measured to throw on the #378 shim — hljs.highlightElement and katex.render both fail, mermaid needs layout), injected through the same libraries field the app fills from the preview's own instances; and DOMPurify.sanitize, a no-op without a real DOM, replaced by identity — what the filter does and where it sits stays pinned by exportSanitize.test.ts.

Two shim additions, documented in place: ShimClassList is now iterable (a real DOMTokenList is, and Array.from(el.classList) was silently yielding [] — without this the highlighting test would have passed for the wrong reason), and CSSOM is modelled as one rule per cssText with the owning sheet's href.

Existing structural guards were followed to the new location rather than relaxed: singleImplementationConvention now pins richContent.ts as the sole mermaid.render( / dompurify / renderRichContent(options site.

npm run check   435 files, 0 errors
npm test        478 / 478
cargo test      131 / 131
npm run build   clean

Not covered

• theme: 'system' with diagrams. The page follows the reader's OS, but the SVG is baked with the exporter's preference — a system-dark author's export read on a light machine gets a light page with dark diagrams. A script-free fix needs two SVGs behind prefers-color-scheme.
• Real library output is not asserted — only that the pipeline hands them the right elements and places the results correctly.
• Dev-mode font base: Vite injects CSS as <style> with no href, so the base falls back to location.href. It works there because dev paths are absolute; untested.
• Monaco's codicon @font-face is left untouched and still dead in exports — unchanged, and it never applies inside .markdown-body.
• Diagram renders are serial awaits, so a document with many diagrams takes proportionally longer with no progress indication.

🤖 Generated with Claude Code