Module body 

Body prose → HTML, in whichever grammar the document is written in.

Three stages run in order:

1. preprocess_custom_syntax rewrites Diaryx-specific syntax (highlights, spoilers, HTML embeds) into raw HTML, skipping fenced/inline code.
2. render_body parses the result as the document’s ContentFormat and renders it, via twig (through prov::render_html).
3. With the syntax-highlighting feature, [crate::syntax] colours the fenced code blocks in that HTML. Third rather than woven into stage two because prov::render_html is one string-to-string call with no node hook — and being a pass over the output is what lets it cover all three grammars, hand-written HTML bodies included, with one implementation.

Why twig rather than a Markdown-only parser

This crate used to run comrak, which meant Diaryx could only ever publish Markdown, and meant the publisher parsed a document with a different engine than the editor did — the editor has always been twig, through leaf. One engine for three grammars is the whole reason content_format can exist: twig is already linked into every build (via prov and leaf), it ships a wasm32-unknown-unknown package so this crate stays portable to the Cloudflare worker, and it covers what comrak covered — tables, strikethrough, tasklists, footnotes, autolinks, raw-HTML passthrough.

Its HTML is not byte-identical to comrak’s: tasklists come out as <ul class="task-list"> and footnotes as role="doc-endnotes" with #fn1 anchors rather than comrak’s #fn-1. html_format_css.css styles both spellings, so a site published before this change and one published after render the same.

Functions

preprocess_custom_syntax

Pre-process Diaryx’s custom syntax (highlights, spoilers, HTML embeds) into raw HTML before the body is parsed. Every stretch the document’s own parser calls code — or raw HTML — is copied through untouched, so a fence showing ==highlight== stays a fence showing ==highlight==.

render_body

Render a document body to HTML.