` laid over the element, `aria-hidden`, with no pointer input;
- inside it one `
` for the dot field, the guides, the outline, the parts and the labels;
- for text and images, a `` or two (the halftone, the colour dot matrix) and an SVG `mask-image` on each text block so glyphs can be inked in one at a time;
- a `requestAnimationFrame` loop that maps elapsed time to a progress `p` and rewrites attributes.
There is no WebGL, no shader and no network call. The element itself is hidden at the start (`opacity: 0`), and at the end the runtime restores its inline `opacity`, `clip-path` and `filter` and removes the overlay. The whole public API is `generate(el, options)`, which returns `{ finished, cancel, element }`, plus `auto()` for a `data-t-generate` attribute and `timeline()` for scrubbing.
Here is a frame from the author's own clip. The card on the left is mid-build: a dot field, a dotted outline with corner handles, every part traced, a size label counting `300 × 340 t+1.76s`, a reticle on the part being drawn.
` up to 120 px, path by path, with its real `getScreenCTM()` transform.
- **Key elements**: interactive boxes first, then the largest, up to 5. These get their own guides, corner handles and a size label.
- At most 60 parts; past that the largest are kept.
Then one function, `frame(G, p, t, D)`, draws everything as a function of progress. The phases are fixed fractions of `duration` (default 2,400 ms), copied here from the `PH` table in the source:
| Phase | Window of `duration` | What happens |
|---|---|---|
| Dot field | 0 to 0.30 | A 15 px grid ripples out from the centre; matrix rain runs down its columns until about 0.86 |
| Probe | 0.02 to 0.24 | A dotted vertical line sweeps left to right, lighting the dots it passes |
| Guides | 0.04 to 0.30 | Four lines along the edges, running past the corners |
| Outline | 0.10 to 0.42 | Both halves from the top centre; handles pop in; the size label counts up |
| Parts | 0.28 to 0.74 | Each part traced in document order; each takes 0.2 of the build, starts spread evenly |
| Reveal | 0.74 to 1.055 | The real element comes in behind a scan line, fading and un-blurring from 3 px |
| Clean | 0.84 to 1.04 | The dot field and guides fade out |
The overlay is removed at `duration × 1.09`, so a default run is about 2.6 s (**reasoned**: 2,400 × 1.09 = 2,616 ms). The drawing eases on `cubic-bezier(0.16, 1, 0.3, 1)` and the reveal on `cubic-bezier(0.22, 1, 0.36, 1)`, which is transitions.dev's `--ease-smooth-out` token. Scrub it below. The card is mine and the drawing is simplified (no rain, probe, reticle or handles), but the windows, the grid, the dot spacing, the part schedule and both curves are the runtime's.
` with `stroke-linecap: round` and a dash array of zero-length dashes:
```js
// ui-generation.js, drawStroke(): n dots, one every 4.8 px, then a long gap
s.el.style.strokeDasharray = `${"0 4.8 ".repeat(n - 1)}0 ${L + 10}`;
s.el.style.strokeDashoffset = -((t * 0.016) % 4.8); // the dots keep flowing
```
A zero-length dash with a round cap paints a dot whose diameter is the stroke width (2.1 px by default). How far the line is drawn is just how many dots are in the array; `getTotalLength()` gives `L`. The offset slides with time, so the dots creep along the line in its drawing direction even after it is complete. A moving "head" circle sits at `getPointAtLength()` of the current end. The outline is two of these, each half of the rounded rectangle from top centre to bottom centre, which is why it grows symmetrically.
The dot field is not a trick at all. It is one `` per grid point, 15 px apart, from 30 px outside the element to 44 px past its far edge, and every frame sets `opacity` and `r` on every circle and toggles a class. That is the cost centre; I come back to it below.
## The text variant: glyphs by marching squares
For display type, the outline of every glyph is traced, not guessed. `glyphLoops()` draws each character alone on a canvas in the element's computed `font`, at 2x when it is under 64 px, and reads the alpha channel back with `getImageData`. It runs marching squares at a threshold of 128 to get closed contours, simplifies each with Ramer-Douglas-Peucker at 0.3 px, drops loops whose bounding box is under 1.5 px², and sorts by area so the outer shape is traced before the counters (the hole in an "e" comes after its bowl). Each contour becomes one dotted path.
The ink then comes in through a mask. Each text block gets an SVG `mask-image` with one rectangle per glyph whose `fill-opacity` rises when that glyph's outline is done plus `fadeDelay` (140 ms), over `fade` (90 ms), at least `fadeStagger` (90 ms) after the previous one. A `sequenceEase` curve, `[0.37, -0.02, 0.73, 0.88]` by default, spreads the glyph start times across the build. Text under 32 px gets the `small-text` treatment instead: one dotted line through each line of text, characters fading in as it passes.
## The image variant: sketch, halftone, colour, photo
For a photo, the runtime reads its pixels (so it has to be decoded, and cross-origin images without CORS get a flat dot screen instead). In order:
1. **Frame**: a dotted frame from the top centre, a size label and a live status.
2. **Sketch** (0.08 to 0.38 of the image's own timeline): luminance on a 3 px grid, stretched between its own 1st and 99th percentile, box-blurred, then marching squares at six tone levels (0.14 to 0.84). The contours are smoothed with Chaikin, cut into strokes of at most 240 px so the sketch builds in many places at once, and kept longest-first within a length budget. A topographic drawing of the photo.
3. **Screen** (0.2 to 0.56): a halftone, one dot per 3 to 5 px cell, sized by tone with the local contrast lifted (tone plus twice its difference from a blurred copy), sweeping in from the top left. Landed dots are painted once into a settled canvas, so they cost nothing afterwards.
4. **Colour** (0.52 to 0.68): the grey dots cross into a dot matrix in the photo's own colours.
5. **Photo** (0.64 to 0.88): the real image fades in from a 6 px blur.
Here are four of my frames of all three variants at once, a headline, a subtitle and the skill's demo canyon photo, scrubbed with `timeline().seek(ms)` so each frame is exact.
` when the response arrives. Confirm?"), then install and wire it with a small diff.
- **Do not rewrite the runtime.** "They are tuned together: the drawing phases, the dot spacing, the flow speed and the reveal curve." The agent copies four files and writes the call.
- **Wiring per framework**: vanilla, the attribute API, React (`useLayoutEffect` with `run.cancel()` as cleanup), Vue and Svelte. And twelve common mistakes, nearly all about measuring too early: before fonts load the glyphs are traced in the fallback face; before an image decodes its sketch is empty; on `display: none` there is nothing to measure.
That list is the most useful thing in the file: the effect is only honest if it measures the final layout. It is the same pattern I saw in [Impeccable](/articles/impeccable-design-skill) and [Anatomy](/articles/anatomy-machine-skill): the skill carries the judgement, and a deterministic artifact (a linter there, a figure kit there, a runtime here) carries the craft, so the agent cannot drift on the parts that need to be exact.
## What it costs
**Bytes.** `ui-generation.js` is 36,364 bytes and `text-image-generation.js` 55,695; the two CSS files are 4,231 and 3,776 (**measured**). With `gzip -9` that is 12,949 + 19,650 + 1,533 + 1,451 = 35,583 bytes (**measured**, summed). One catch: `ui-generation.js` imports the text and image module statically, so a page that only uses the `ui` variant still ships 92,059 bytes of JavaScript, 32,599 gzipped (**reasoned** from the two measured sizes). A dynamic `import()` for the four non-ui variants would save the larger file for the common case. The site's own copy at `assets/ui-generation/ui-generation.js` does not import it at all, and has a `reveal: "fade"` option the skill copy lacks (**measured**, by `diff`). So there are already two forks of the runtime in one repository.
**The dot field.** Every frame touches every dot. The grid rule is easy to compute, and I checked it against the overlay in the browser: the Heart Rate Monitor card at 332 by 345 px gets a 28 by 28 grid, 784 circles, inside an overlay of 947 nodes; the skill demo's three cards together carry 2,904 dots and 3,576 overlay nodes (**measured**). Drag the sizes below; the grid grows with area, so a full-width hero costs several times a card.