Frontend Slides

---
name: frontend-slides
description: >
  Build zero-dependency, animation-rich HTML presentations — from a topic,
  from rough notes, or by converting an existing PowerPoint deck to the web.
  The distinguishing discipline is two hard gates most slide generators skip:
  (1) every slide must fit exactly one viewport with no internal scroll, and
  (2) non-designers are guided to a distinctive look through visual
  exploration (real preview slides they can react to) instead of abstract
  style questionnaires. Produces a single self-contained .html file with
  inline CSS/JS, keyboard/wheel/touch navigation, reveal-on-enter animation,
  and reduced-motion support. Use when someone wants to create a talk, pitch,
  workshop, or internal deck; convert a .ppt/.pptx to HTML; or fix the layout,
  motion, or typography of an HTML deck that already exists.
metadata:
  activation_triggers:
    - build a presentation / slide deck / pitch deck / talk deck / workshop deck
    - convert ppt / pptx / powerpoint into html slides
    - improve layout, motion, or typography of an existing HTML deck
    - explore presentation styles with someone unsure of their aesthetic
    - slide overflow, viewport-fit, scroll-snap, or reveal-animation problems
version: 1.0.0
risk_class: low
source: affaan-m/ecc@81af4076 skills/frontend-slides/
license: MIT
---

# Frontend Slides

Generate a browser-native presentation that runs from a single local `.html`
file with no build step and no runtime dependencies. The value of this skill
over a generic "make me slides" prompt is two enforced gates — **viewport fit**
and **style discovery by preview** — plus production-quality navigation and
accessibility baked in.

## When to Activate

- Someone wants a talk deck, pitch deck, workshop deck, or internal update deck.
- Someone hands you a `.ppt`/`.pptx` and wants it as a web presentation.
- An existing HTML deck needs better layout, motion, or type — or a slide is
  overflowing/scrolling and must be made viewport-safe.
- Someone wants to "make it look good" but cannot name a style — drive style
  discovery through previews, not a questionnaire.

## Non-negotiables

1. **Zero dependencies.** Default to one self-contained HTML file, CSS and JS
   inline. Fonts from a web font host are the only external fetch.
2. **Viewport fit is a hard gate.** Every slide occupies exactly one viewport
   and never scrolls internally. This is the section that fails most decks —
   treat it as a blocking check, not a nicety.
3. **Show, don't ask.** Discover the aesthetic with real preview slides the
   person can look at, not adjectives.
4. **Distinctive by default.** Avoid the generic look (a purple gradient,
   a neutral grotesk on white, template chrome). Commit to a direction.
5. **Production quality.** Commented, accessible, responsive, performant.

## Workflow

### 1. Detect the mode

- **New deck** — a topic, notes, or finished copy.
- **Conversion** — a `.ppt`/`.pptx` to bring to the web.
- **Enhancement** — HTML slides that already exist and need work.

### 2. Discover the content

Ask only the minimum: purpose (pitch / teaching / conference / internal),
rough length (short 5-10, medium 10-20, long 20+), and content state
(finished copy / rough notes / topic only). If they have copy, get it pasted
before you style anything.

### 3. Discover the style (default path: visual exploration)

If the person already knows the direction, use it and skip previews.
Otherwise:

1. Ask what the deck should make the audience *feel* — impressed, energized,
   focused, or moved. One word is enough to pick a direction.
2. Generate **three single-slide preview files** in a scratch directory
   (e.g. `slide-previews/`). Each is self-contained, shows type + color +
   motion clearly, and stays small (~100 lines of slide content).
3. Let them pick one, or mix elements across two.

Map feeling to a concrete direction (voice + palette + motion) using
`references/viewport-and-motion.md`. Teach yourself the *method* of committing
to a distinctive direction rather than reaching for a default — the reference
gives archetypes (editorial-serif, technical-mono, high-contrast keynote,
soft-geometric, atmospheric-dark) as starting points to adapt, not a fixed
brand list to copy.

### 4. Build

Output `presentation.html` (or `<name>.html`). Use an `assets/` folder only
when the deck carries extracted or user-supplied images.

Required structure:

- semantic slide sections (`<main>`, `<section>`, `<nav>`);
- the viewport-safe CSS base from `references/viewport-and-motion.md`;
- CSS custom properties for every theme value (one edit re-themes the deck);
- a small presentation-controller class for keyboard, wheel, and touch nav;
- an `IntersectionObserver` that adds a `visible` class to drive reveals;
- `prefers-reduced-motion` handling.

### 5. Enforce viewport fit (the hard gate)

- Every `.slide` uses `height: 100vh; height: 100dvh; overflow: hidden;`.
- All type and spacing scale with `clamp()` — never fixed px for body copy.
- When content will not fit, **split into more slides** — never shrink text
  below readable size and never allow a scrollbar inside a slide.
- Apply the short-height breakpoints (700 / 600 / 500 px) from the reference so
  landscape phones and short laptops still fit.

### 6. Validate

Check the finished deck at 1920x1080, 1280x720, 768x1024, 375x667, and
667x375. If browser automation is available, drive it to confirm no slide
overflows and that keyboard navigation advances slides. (A companion
demo/E2E skill can record or exercise the result.)

### 7. Deliver

- Remove temporary preview files unless asked to keep them.
- Open the deck with the OS-appropriate opener when useful: macOS `open`,
  Linux `xdg-open`, Windows `start ""`.
- Summarize: file path, the style direction chosen, slide count, and the
  handful of CSS custom properties to tweak for re-theming.

## PowerPoint conversion

Keep conversion **cross-platform** — reach for Python, not OS-only tooling.

1. Extract text, speaker notes, and images while preserving slide order. The
   `python-pptx` package (third-party, optional) reads a `.pptx` cleanly:
   iterate slides, pull shape text and the title placeholder, save picture
   blobs to `assets/`, and read `notes_slide` for speaker notes. If it is not
   installed, ask whether to install it or fall back to a manual/export path
   rather than assuming.
2. Preserve slide order, notes, and extracted assets in a small intermediate
   structure (one record per slide: title, body blocks, image paths, notes).
3. Then run the same style-discovery + build workflow as a new deck.

> This skill ships no bundled extractor script — a `.pptx` reader needs a
> third-party parser, which conflicts with the zero-dependency posture. Treat
> the reader as an optional tool the user opts into, and keep the extraction
> logic small and inline.

## Implementation notes

- **HTML/CSS:** inline unless the user explicitly wants a multi-file project.
  Prefer atmospheric backgrounds, a strong type hierarchy, and abstract
  geometry (gradients, grids, noise, shapes) over stock illustration.
- **JavaScript:** keyboard nav (arrows / space / page-up-down), touch/swipe,
  mouse-wheel, a progress indicator or slide index, and reveal-on-enter
  triggers via `IntersectionObserver`.
- **Optional inline editing** (only if the user opts in): gate the visibility
  of any edit UI behind JS classes — do **not** use a CSS `~` sibling
  hover-reveal, because `pointer-events: none` on the button breaks the hover
  chain. When exporting the edited file, strip edit state (`contenteditable`
  attributes, edit-active body class, toggle/banner classes) *before* reading
  `outerHTML`, then restore it — otherwise the saved file opens stuck in edit
  mode. When you capture `outerHTML`, clear generated nav-dots first or they
  duplicate on re-open.
- **Images:** reference by file path (not base64) for local viewing; constrain
  every image with `max-height`; resize anything over ~1 MB; never overwrite an
  original (write a `_processed` copy).

## Accessibility

- Semantic structure (`main`, `section`, `nav`).
- Readable contrast; keyboard-only navigation must work end to end.
- Honor `prefers-reduced-motion` (collapse animation, disable smooth scroll).

## Content density limits

Use these maxima unless the user explicitly asks for denser slides *and*
readability still holds:

| Slide type   | Limit                                          |
|--------------|------------------------------------------------|
| Title        | 1 heading + 1 subtitle + optional tagline      |
| Content      | 1 heading + 4-6 bullets or 2 short paragraphs  |
| Feature grid | 6 cards max                                    |
| Code         | 8-10 lines max                                 |
| Quote        | 1 quote + attribution                          |
| Image        | 1 image, constrained by the viewport           |

## Anti-patterns

- Generic startup gradient with no visual identity.
- System-font decks unless intentionally editorial/utilitarian.
- Bullet walls; tiny type; code blocks that need scrolling.
- Fixed-height content boxes that break on short screens.
- Negated CSS math functions like `right: -clamp(...)` — browsers silently
  ignore them. Use `calc(-1 * clamp(...))`.

## Deliverable checklist

- Runs from a local file in a browser, no build step.
- Every slide fits the viewport with no internal scroll.
- The style is distinctive and intentional, not a default.
- Motion is meaningful, not noisy; reduced motion is respected.
- File path and the re-theming custom properties are explained at handoff.

## Changelog

- **1.0.0** — Initial authored version. Teaches viewport-locked HTML slide
  generation, preview-driven style discovery, cross-platform PPTX conversion,
  and accessible navigation. Clean-room rewrite; the viewport CSS base and the
  motion/style archetypes live in `references/viewport-and-motion.md`.
Skill-Import-Attestation: reviewed-by=AE9B236FDAF0462874060C6BCFCFACF00335DC74; sha256=de4437a4086c12429c3dff77077d6cbdaac922fd7d5137f31540cc97dfe7efab