Open Editorcase 08
Page Skeletons
Loading states drawn from the real page — because they are the real page.
// the problem
Skeleton screens — the gray shimmer blocks a page shows while its content loads — are drawn by hand. A developer eyeballs the layout and writes placeholder CSS; a designer rebuilds the page as gray boxes in a design tool for the spec, the pitch deck, or the loading-state mock. Then the page changes, and the skeleton quietly stops matching it. Every hand-drawn skeleton is a copy of a layout, and copies drift.
// how everyone solves it
Manually, every time: measure the page, redraw its regions as rounded gray rectangles, animate a shimmer over them in CSS or in a motion tool, and re-do all of it when the layout moves. There’s no source of truth linking the skeleton to the page it stands in for — the resemblance is maintained by hand, which is exactly the kind of work that stops happening under deadline.
// the m0saic program
m0saic’s whole worldview is that a page is rectangles — so a skeleton isn’t an imitation of the layout, it’s the layout itself with the content swapped for placeholder fills. @m0saic/web/page-skeleton/v1 takes a captured snapshot of a real page’s geometry — anonymous rectangles, no content, no branding — and renders it as a skeleton still or a looping shimmer / pulse video. Product mocks, loading-state specs, placeholder reels: all from the page’s actual bones, at any resolution, reproducibly.
// run it yourself
One command, straight from a terminal. The CLI carries the template, the engine, and the validator — if the layout can’t render correctly, it fails before a single frame is written.
// read the source
The template behind this study is @m0saic/web/page-skeleton/v1 — a typed, unit-tested program, not a script. The template library is headed for open release; the m0saic source lives on GitHub.