# Slide Canvas

> Build zoomable, Prezi-style presentations as a single HTML file: slide 1 is a map of the whole ta…

Build zoomable, Prezi-style presentations as a single HTML file: slide 1 is a map of the whole talk, every other slide nests inside a part of it, and a built-in presenter flies a camera that zooms into each topic, pans, dives into details and pulls back to the overview. 1920×1080 slides with speaker notes, design tokens, fixed type and 11 layouts with tested word budgets. Use whenever the user asks for a deck, slides, a presentation, a talk, a pitch, a lecture, a keynote, a webinar or a board review, and especially for a "Prezi", "Prezi-style", "zooming", "zoomable", "non-linear", "canvas" or "mind-map" presentation, or one that should "show the big picture" or "zoom in and out", even if they only say "make a presentation about X".

- Page: https://ss33.ai/skills/skillstore33/slide-canvas-41104729661
- Publisher: skillstore33
- Category: [Creative & Media](https://ss33.ai/skills/category/creative-and-media-0j3x01) › [Image & design](https://ss33.ai/skills/category/creative-and-media-0j3x01/image-and-design-nlbt3d)
- License: MIT

## Skill

SKILL.md: https://ss33.ai/api/v1/ss33/download/skillstore33/slide-canvas-41104729661

# Slide Canvas

A slide deck is a row of pictures; a canvas deck is one picture the audience explores. Slide 1 maps the talk, every other slide lives inside a part of that map, and the presenter zooms in, pans across and pulls back, so the audience always knows where they are. The structure is the argument: the overview's title and captions alone should tell the talk, and every zoom should mean "closer look at this", never "something else". Each slide still has to work full screen on its own: one idea, legible from the back of the room in three seconds.

## Start from the starter

`references/starter.html` is the base of the file: tokens, the frame CSS that makes overflow impossible within budget, every layout class, an icon sprite, a 12-slide example canvas (single slide, `map` hub, `visual` hub with SVG portals, sequence) and the presenter `<script>`. Keep its `<head>`, `<style>` (sections 2–5), sprite and presenter; replace the example slides with yours; change only the TOKENS block, `<title>`, the Google Fonts `<link>` and the section-6 style block.

Optional depth, open what you need (all four, in one turn, is the usual choice):
- `read_skill_file("slide-canvas", "references/starter.html")`: always.
- `read_skill_file("slide-canvas", "references/layouts.md")`: each layout's character budgets and skeleton, the bar-chart recipe, the diagram kit. The budgets were tested in wide fonts; stay within them and nothing overflows.
- `read_skill_file("slide-canvas", "references/canvas.md")`: tree rules in full, arrangements, hubs, PLAN format, common mistakes.
- `read_skill_file("slide-canvas", "references/styles.md")`: six style families with tokens, font pairs and style blocks, and a contrast-checked hue table.

## The contract (checked mechanically)

- One self-contained HTML file. Each slide is a top-level `<section class="slide LAYOUT">`, 1920×1080, stacked in presenting order, with `<aside class="notes">` (30–90 spoken words).
- Layouts: `map statement big-number stats chart compare cards process visual quote closing`; modifiers `inverse`, and `path` / `grid` / `scene` on `map`. No other layout classes; no title, section, agenda, divider or "back to overview" slides (the overview is the title; the camera returns to it between topics and at the end).
- Tree: slide 1 is a `map` with 3–5 portals. Every other slide has a unique `id` and appears in exactly one `data-zoom` of an earlier slide. A portal lists 1–4 **exact ids**, space-separated: the presenter matches whole ids, so a topic name or id prefix silently loses those slides. At most three levels (overview → topic → detail); details have no portals. Document order is depth-first: each topic's slides follow it, unbroken by another topic.
- SVG portals (in `map scene` and `visual` hubs) are `<rect data-zoom="id" … rx="12" class="fb"/>` at exactly 16:9 (512×288, 448×252, 384×216, 320×180, 256×144), labelled outside, nothing drawn over them.
- The presenter `<script>` is copied unchanged as the last thing in `<body>`, and is the only script. Placement is its job: no `position`, `transform`, negative margins, fixed sizes or `style=""` on content.
- Type is fixed by the CSS: never set `font-size` outside SVG text, never `<br>` in headings. SVGs always have a `viewBox`, no `width`/`height` attributes, text ≥ 26 units, everything inside.
- No invented image URLs (photos are `.slot` placeholders), no emoji, fonts from one Google Fonts `<link>`.

## The bar

- **Story as a tree.** 3 topics for 6–8 slides, 3–4 for 9–12, 4–5 for 13–16. Mix topic kinds: a single slide, a sequence (camera pans), a hub (camera dives); a canvas where every topic is one slide is a slide deck with zoom. Choose the overview arrangement for what it means: `scene` when the subject is a thing or place with parts (zooming in *is* looking closer), `path` for a sequence, `grid` for exactly four parallel parts, a row otherwise. Where the subject has a physical or structural side, put at least one zoom on a part of a drawing that opens into its own slide: it is the strongest moment a canvas has.
- **Two distances.** A topic's first slide is seen growing out of the map, so make it a cover (big, short: `statement`, `big-number`, `visual`, hub `map`); keep `stats`, `compare`, `chart` for later. Captions are names; the slide inside says the takeaway.
- **Action titles.** Every `h2` is a sentence stating the takeaway; the headlines alone tell the story.
- **Few words.** ≤ 40 visible words a slide, most 15–30; data slides (`chart`, `stats`, `compare`) up to 55 for labels and context. When over budget: cut, move explanation to notes, split, or change layout; never shrink type.
- **Variety and visuals.** No layout twice in a row (two `map`s excepted), ≥ 6 layouts in 8–12 slides, a chart, diagram or icon cards at least every third slide. Numbers shown as numbers or charts.
- **Fidelity.** Only the brief's facts, never invented. Every figure in its tables and lists appears on a slide as given (notes don't count); shorten without losing precision (`3,250` → `3.25k`, not `3k`). Data decks: every series in full, every worsened metric charted, plan vs actual as paired bars or a two-number `compare`. If the brief lists slides one by one, keep them and their order: its first slide becomes the overview, the rest become 3–5 runs of consecutive slides as sequences or hubs.
- **Charts are computed**, not drawn by eye (recipe in `layouts.md`: baseline y=520, tallest bar 420 high, labels 18 above); accent only on the bar the headline is about. Never a line over bars.
- **Emphasis.** Accent on the kicker, the key number or bar, and at most one `<em>` per slide. No half-empty slides; a lone number gets its comparison or meaning.

## Look

Decks from this skill converge on one look unless you push against it, so choose deliberately: name the cliché for the topic (energy → green, finance → navy, health → teal) and avoid its hue unless it is the brand colour; pick the family in `styles.md` that fits the audience and room (Dark stage is wrong for dim projectors and long rooms) rather than your habitual one; choose an accent from an object in the subject's world, using the contrast-checked values in the hue table. Paste the family's tokens, fonts and style block as given; they never touch sizes or the frame, so the budgets still hold.

## Plan and deliverable

Put a PLAN comment inside `<body>` before slide 1: a `CANVAS | arrangement | metaphor` line, one line on the look (cliché avoided, family, fonts, accent), then one line per slide: `NN layout | headline | overview` or `in NN · id`.

Your reply after reading is the complete file in one ```html block ending with `</html>`: the plan lives inside it, never as a message of its own. After the block, 2–4 lines: the arrangement and its topics, the look, any placeholder to replace (photo slot, illustrative quote), and that P in Chrome presents the canvas (arrows move, the camera returns to the overview between topics).

Before sending, check the two things strong models still miss: every id appears exactly once across all `data-zoom`s, spelled exactly, and the presenter script is present and unchanged.