Syntax Highlighting

Created May 28, 2026Updated Jul 24, 2026Takeshi Takatsudo

Build-time class-mode highlighting with semantic tokens that follow the active zudo-doc color scheme.

Core feature — always active, no configuration required.

What it does

Every fenced code block is highlighted at build time by zfb's native class-mode highlighter. The highlighted HTML is embedded directly in the SSR output — no JavaScript is required in the browser.

Theme

zfb emits semantic classes such as hi-kw, hi-str, hi-num, and hi-com under a pre.hi-root wrapper. zudo-doc maps those roles to its --zd-syntax-* design tokens through the --zfb-hi-* CSS bridge. Switching the active zudo-doc color scheme therefore recolors existing code without rebuilding the page or running a client-side highlighter.

This contract is package-owned: generated projects do not emit a renderer or theme-name block in zfb.config.ts.

Supported languages

Specify the language identifier on the opening fence:

```ts
const greeting: string = "hello";
```

Renders as:

const greeting: string = "hello";

Without a language identifier, the block is rendered as plain text with no highlighting.

Emitted markup

A highlighted code block renders as:

<pre class="hi-root">
  <code><span class="hi-kw">const</span> <span class="hi-var">greeting</span> …</code>
</pre>

When used together with the Code Title feature, the <pre> is wrapped inside a .code-block-container div. The copy and word-wrap buttons visible in the UI are injected by client-side JavaScript and are added to every code block automatically — independent of the opt-in Code Enrichment feature, which only adds diff/line/word-highlight decorations.

Processing order

The syntax highlighter runs in zfb's build pipeline after code-block structure has been prepared. Features that annotate a structured <pre><code> block run before class-mode output is finalized.

Code titles, copy and wrap controls, line and word emphasis, diff markers, tabs/code groups, Mermaid, and plain fallbacks remain separate structural features. They do not introduce a second token palette.

Shared runtime contract

The HtmlPreview source panel uses the browser-time @takazudo/zfb-md-wasm renderer, but it emits the same pre.hi-root / hi-* vocabulary and consumes the same syntax design tokens. The WASM module is loaded only when a source panel is opened (or initially rendered with defaultOpen); changing a color scheme or editing a syntax token recolors the existing DOM without rerunning either renderer.

Migration from theme-name output

Current zudo-doc projects do not configure codeHighlight.themeLight / themeDark, consume --shiki-* variables, or install Shiki for HtmlPreview. Remove those project-owned settings and palette rules when upgrading. Existing color schemes remain compatible: every syntax role inherits an existing semantic color unless the scheme provides a syntax-specific override. See Color — Syntax semantics.

Notes

Document fences contain semantic classes and no inline palette colors.
Both build-time and HtmlPreview highlighting use zfb renderers; Shiki is not a runtime or peer requirement.

View source on GitHub