`, `
Explanation text
function example() {
return "Same size as body text";
}
Explanation text
// WRONG: text-base (16px) < text-xl (20px)
First explain the concept
# Code appears after explanation
def example():
return "builds understanding"
# Old approach
# New approach
First introduce the concept
...example code appears lastThis
causes
click
fatigue
``` **Fragment modifiers:** - `fragment fade-in` - Default - `fragment fade-in-then-semi-out` - Highlight then dim - `fragment highlight-current-blue` - Highlight temporarily ## Editing Existing Presentations **When adding to or modifying existing presentations:** 1. **Read entire file first** - Understand full structure and patterns 2. **Identify and match patterns:** - Background colors: Note alternating pattern (e.g., #1e293b, #0f172a) - Typography: Check existing heading sizes, body text sizes - Code blocks: Match existing code font size (`text-base` or `text-lg`) - Speaker notes: Match existing format (timing markers, detail level) - Fragment usage: Follow existing progressive reveal patterns 3. **Update related content:** - If changing slide content, update speaker notes to match - Maintain semantic color usage (green=good, red=bad, etc.) - Keep same transition style throughout 4. **Verify rendering:** - All changes display correctly - No overflow or layout breaks - Consistent with surrounding slides **What to preserve:** - Color palette and background patterns - Typography scale hierarchy - Code sizing conventions - Speaker note format and detail level - Fragment usage patterns **What to refactor anyway:** - Inline styles → Tailwind CSS (always) - Class-based slides → data-background-* attributes (always) - Missing speaker notes → Add with timing markers (always) - Code smaller than body text → Fix to text-base minimum (always) ## Quick Reference | Feature | Example | |---------|---------| | Tailwind styling | `class="text-4xl font-bold text-blue-600"` | | Slide backgrounds | `data-background-color="#1e293b"` (alternate #0f172a) | | Code blocks | `` |
| Speaker notes | `` |
| Fragments | `- Item
` (build complexity, not click fatigue) |
| Multi-column | `` |
| Semantic colors | Green=good, Red=bad, Yellow=warning, Blue=neutral |
| Typography scale | Code >= body text (`text-base` min for code, `text-xl` for body) |
| Auto-animate | Same `data-id` across slides |
| Overview mode | Press ESC/O |
## Essential Configuration
```javascript
Reveal.initialize({
slideNumber: 'c/t',
hash: true,
width: '100%',
height: '100%',
transition: 'slide',
controls: true,
progress: true,
keyboard: true,
overview: true,
plugins: [ RevealMarkdown, RevealHighlight, RevealNotes ]
});
```
## Workflow
**STEP 0:** Pre-flight check (above) - refactor if needed
1. Set up Tailwind if not present
2. Plan structure: horizontal (main) vs vertical (detail)
3. Content on slides: high-level only
4. Add formatted speaker notes with timing markers to ALL slides
5. Detail in notes, not on slides
6. Add effects LAST (only where they serve purpose)
7. Verify rendering:
- Code examples: Syntax highlighting works, `text-base` or `text-lg` sizing (never smaller than body text)
- Fragments: Progressive reveal works as intended, no "click fatigue"
- Multi-column: Grid layouts don't overflow or break
- Speaker notes: Detailed with timing markers for every slide
- Colors: Semantic meaning clear (green=good, red=bad), sufficient contrast, symbols complement colors
- Typography: Heading hierarchy consistent, code >= body text size
## Common Rationalizations (STOP)
| If you think... | Reality |
|----------------|---------|
| "Maintain visual consistency" with inline styles | STOP. Refactor to Tailwind |
| "Avoid introducing complexity" | STOP. Bad code IS complex |
| "Original didn't use Tailwind" | STOP. Refactor anyway |
| "This transition draws attention" | STOP. Define actual communication goal |
| "Slide structure guides narrative" | STOP. Add speaker notes anyway |
| "User asked for it quickly" | STOP. Refactoring is faster than tech debt |
| "Code will be readable at default size" | STOP. Set `text-base` or `text-lg` explicitly - never smaller than body text |
| "Presenter can ad-lib this section" | STOP. Add detailed speaker notes with timing markers anyway |
| "Need to show complete code example" | STOP. Split into 3-8 line chunks across slides with fragments |
| "Text-sm fits more code in two columns" | STOP. Use `text-base`, reduce code lines, or make columns wider |
| "Speaker notes take too long to write" | STOP. 3-5x detail ratio is mandatory - saves presenter time during talk |
| "Fragments on everything make it interactive" | STOP. Causes click fatigue - use only for building complexity |
| "Monospace is more readable at smaller sizes" | STOP. Code must be >= body text size - non-negotiable |
| "Balance readability and space" | STOP. Reduce code lines or use larger body text - code size is fixed |
| "Code slightly smaller is fine" | STOP. **NO EXCEPTIONS** - code >= body text always |
## Accessibility Checklist
- [ ] Semantic HTML (heading hierarchy)
- [ ] Keyboard navigation (Tab, arrows, ESC)
- [ ] Speaker notes provide context
- [ ] Color contrast sufficient
- [ ] No information by color alone
- [ ] Alt text for images