three things to try

• edit a heading on this slide, then arrow-key to slide 1 — your change is still there
• open the log panel from the toolbar to see the structured op-log entries
• jump to the design-system slide and drag a color — the deck recolors live

what won't break

• arrow-key navigation pauses while you're typing in a contenteditable
• refresh the page: ops persist in localStorage, the deck re-renders the way you left it
• hit revert in the toolbar to drop unsaved ops and reload from disk

shape

{
  kind:   "content",
  path:   "section:2>div:1>p:0",
  before: "edit HTML in the browser",
  after:  "edit any HTML page in place",
  ts:     "2026-04-27T14:08:33.412Z"
}

two kinds today

• content — text edits to a node addressed by structural path
• theme — CSS variable overrides; saved into <style id="theme-overrides">

why path, not id

• most authored HTML doesn't sprinkle ids on every paragraph
• structural paths are stable while editing in place — you rarely reorder siblings mid-session
• nodes that move trigger a re-anchor on next save; pathological reorders show up as a regenerated op set, not silent drift

coalescing rule

• same opKey (path or token), same direction, within 30s ⇒ merge after-state, drop intermediate
• typing a word doesn't make 8 ops; it makes 1
• if the merged op cancels itself (before === after), it pops off the log

undo / redo

• walks the array, not the browser undo stack
• truncates forward log when you edit after an undo (familiar git/editor semantics)
• head pointer separates applied from redoable

chrome / edge — write back

• first save asks for a writable handle on the original file via showSaveFilePicker / createWritable
• handle cached in IndexedDB; subsequent saves are silent
• save = clear log + write disk

safari / firefox — download

• same pipeline, last step swaps to <a download>
• you replace the file by hand once; nothing else changes
• this docs page runs in download mode (Pages is read-only)

theme overrides bake into one block

CSS-variable edits don't pile up as inline styles. Every theme op collapses into a single <style id="theme-overrides"> block at save time:

<style id="theme-overrides">
:root{
  --accent:  #f07fcc;
  --t-h1:    31px;
  --t-body:  15px;
}
</style>

variables, not values

• change --accent once → every h3, link, focus ring, and pill recolors
• change --t-h3 once → every section heading in the deck rescales
• the entire visual identity is ~16 tokens; the rest is plumbing

why this works in a live editor

• tokens compose: a swatch picker is a one-line CSS variable write
• the live preview is the page itself — no separate Storybook
• theme ops are first-class citizens of the op log, not a side channel

live-html ships as an installable Claude Code skill at ~/.claude/skills/live-html/. When Claude is asked to author a deck, dashboard, or status page, the skill triggers and the generated HTML drops in with the editor pre-wired.

what's in the skill

• SKILL.md — trigger phrases, when to invoke, when not to
• ARCHITECTURE.md — op-log, paths, save pipeline, theme bake
• recipes/ — copy-paste templates per page shape (deck, dashboard, doc)
• editor.css + editor.js — the artifact itself, vendored

why it matters

• AI generates the first draft — usually 80% there, 20% off
• without live-html, the user opens the file in an editor and re-prompts
• with live-html, the user clicks the typo and retypes it; the file updates
• the human-in-the-loop becomes a 1-second click instead of a context-restoring prompt

not for collaborative editing

No CRDTs, no presence, no merge. Two people editing the same file at the same time will overwrite each other on save. Use a real CMS or a Notion / HedgeDoc / Etherpad if you need shared cursors.

not for one-shot generated content

If the artifact is throwaway (a chat-rendered preview, a single-use report), the editing loop adds zero value. Render and discard.

not for review-gated changes

Click-to-edit is the opposite of "request approval, get review, merge". If your content needs a PR, use a PR. live-html is for the case where the author is also the reviewer.

not for live-data dashboards

Reactive dashboards reading from a websocket or polling an API are a different shape. live-html edits HTML, not data bindings. (Recipe: combine live-html for layout/labels with a separate fetch loop for data — works fine, just be deliberate.)

theme switching

• named themes (light / dark / contrast / sepia) as first-class config
• new op kind: theme-switch — swap the active theme name without rewriting tokens
• users layer personal overrides on top of a chosen base

local co-edit server

• tiny local server (~150 LOC) that brokers human + agent edits on the same file
• agent posts ops; the human sees them appear in the toolbar log; either side can save
• opt-in only — the default stays "no server, no install"

tiptap upgrade for structured edits

• contenteditable handles plain text well; lists, links, code blocks need more
• swap the editing layer to Tiptap when richer ops are needed; keep the op-log shape stable
• still no build step — ship Tiptap as a single bundled file

.history/ snapshot dir

• on each save, also write a timestamped snapshot to a sibling .history/
• poor-man's local time-travel; meaningful when not under git
• pruned by count + age, configurable