Slides have an odd status in engineering: we make them constantly, but we treat them as disposable. They rarely live in a repo. They rarely go through review. The diagram you spent twenty minutes aligning in Keynote is gone the moment the talk ends.
Dinghy's Slide Builder treats a slide like any other artifact: a folder of source files that compiles to a single deliverable.
What it is
A presentation builder layered on top of RevealJS, wired into the same Dinghy CLI you already have:
- YAML DSL: recognized keys map to semantic blocks, and any other key becomes the matching HTML element, so you describe slides in a structured, indented form.
-
Markdown and HTML, auto-loaded: drop a
.mdor.htmlfile in the slide folder and it becomes a section. - Self-contained HTML output: assets inlined, a single file you can share or host anywhere.
-
Live reload dev server: run
dinghy slide startand edit-to-reload feedback. - Prezi-style zoom and pan: exclusive to Dinghy, covered below.
A YAML slide
The core idea is that a slide is a tree of HTML elements, and YAML is a tidy way to describe nested structure:
sections:
- badge: Show Case
title: Slide Builder
subtitle: author RevealJS presentations in YAML
ul:
li:
- YAML DSL maps keys to HTML elements
- Self-contained HTML output
- Live reload development server
Some keys are recognized aliases: badge becomes <div class="badge">, title becomes <h2 class="title">, subtitle becomes <p class="subtitle">. Any other key, such as p, h3, ul, or li, becomes that HTML element directly. Multi-file slides are just multiple YAML files in the same folder, picked up in filename order.
A Markdown slide
If you want to add a section quickly, plain Markdown works:
## Slide Builder
- YAML DSL maps keys to HTML elements
- Self-contained HTML output
- Live reload dev server
Markdown files become slides automatically. You can mix YAML, Markdown, and raw HTML in the same slide and use whichever fits each section.
The single-file output
Run dinghy slide build and you get one HTML file, with every image, font, and dependency inlined. There is nothing to host. You can drop it into a chat, open it offline, or email it. RevealJS rendering is intact, navigation works, and the speaker view works.
This matters for talks at venues with unreliable WiFi: your slide is a self-contained file that depends on nothing but a browser.
The Prezi-style feature
The one part that is exclusive to Dinghy is zoom-and-pan slides. You give an image and a set of regions by pixel coordinate, and the slide zooms into each region in turn instead of cutting to a new one:
- id: dinghy-proxy-project
img: imgs/dinghy-proxy-project.png
width: 1562
height: 1398
sections:
- id: dinghy-proxy-title
x1: 71
y1: 842
x2: 954
y2: 1132
- id: dinghy-proxy-ruby
title: ❤️
x1: 1052
y1: 119
x2: 1550
y2: 293
The slide flies into each rectangle in turn. This is useful for architecture diagrams you want to walk through region by region without redrawing them five times. Under the hood it builds on RevealJS's data-auto-animate to morph between views, but the coordinate-based syntax is unique to Dinghy: in plain RevealJS you would have to calculate the CSS transforms by hand.
Why bother
The same reasons authoring in source pays off everywhere else:
- The slide lives in the repo, gets reviewed, and gets diffed.
- Change a shared section once, and every slide that includes it updates.
- The output is one file, not a Keynote bundle, not a Google Slides URL, not a link that only works on the company VPN.
If you give more than a couple of talks a year, the cost of authoring in YAML is repaid by the sixth or seventh slide.
See it in action
The Introduction to Dinghy slide is built with the Slide Builder. It is a live example of the YAML DSL, the auto-loaded multi-file layout, and the Prezi-style zoom-and-pan described above. The source is on GitHub.


Top comments (0)