Skip to main content
Each recipe below is a complete section: the lines for script.md, the entry for cues.json, and the scene for deck/index.html. They use the stylesheet that decktalk init writes, so paste them into the scaffold and build. They are recipes rather than copies of the scaffold, whose own scenes are walked through in Your first deck. The scene and step ids are placeholders, and any section number works as long as the same number appears in the script heading, the [[section]] table, and the cues.json key.
Inside the backticks of a render template, write every backslash twice. The data-tex value \\frac{d}{dx} reaches KaTeX as \frac{d}{dx}, and a single backslash is swallowed by the template literal.

A subtitle that follows the voice

An element with data-sync reveals one word at a time, each at the second the voice reaches it, so a line on the slide keeps pace with the narration. The scaffold uses it for the subtitle of its title scene and for the three lines of its closing recap. The text must be word for word what the voice says, because the runtime matches it against the section’s spoken words, ignoring case and punctuation, and prefers the run nearest the cue. Give it data-fx="none", since a fade on the container fights the per-word reveal.
script.md
cues.json
deck/index.html
The cue mounts the line, and the words arrive from there. A line whose text differs from the script by one word reveals whole, and the recorder logs data-sync text not found in the spoken words. In a browser, ?scene=5 reveals each line whole, because the preview has no word times. The runtime reference has the rules.

A derivation that reveals line by line

This derivation is a recipe rather than a scaffold scene. Each line is its own element with its own cue, and data-display typesets it as display math. The answer uses pop so that it lands harder than the steps.
script.md
cues.json
deck/index.html
The plain text inside each element is what shows when KaTeX is absent, so write it as a readable fallback.

A chat before and after

The question types in with data-type, and the reply fades in one line at a time. The bubble and its first line share a cue, so the bubble’s background appears at once while the text arrives. The second step is the “after”, and its cue 4.2 mounts it. The scaffold’s own before-and-after scene syncs each prompt to the voice with data-sync instead, which suits a prompt the narrator reads aloud.
script.md
cues.json
deck/index.html

A code block that reveals one line per phrase

Each line is a block element with its own cue. A container with white-space: pre and a monospace font keeps the indentation, and fade avoids the vertical motion of rise, which looks wrong on code.
script.md
cues.json
deck/index.html
Keep the lines on one physical line inside the render template, because white-space: pre would otherwise render the template’s own indentation.

A two-column comparison

Two columns, each with a heading and a caption, revealed left then right. The flex cols class from the scaffold lays them out, and each column gets one cue.
script.md
cues.json
deck/index.html

A screenshot slide that waits for the image

The recorder starts the narration clock only after window.__sceneReady resolves, so a page with a large image should set that promise to the image’s decode. Set it in a script that runs before the runtime starts, because the runtime sets its own promise only when the page has not. The image is decoded into the browser’s cache, so the img element inside the step appears at once when its cue fires.
script.md
cues.json
deck/index.html
A page that sets its own __sceneReady and also uses data-tex should wait for window.katex itself, because the runtime’s KaTeX wait is part of the promise it would otherwise have set. The runtime reference has the details.

Next

The page contract has the sizes and margins that keep text readable at 1920 by 1080, and a table of which reveal effect suits which element.