We kept a 225KB HTML file forever, and it has caught every regression since

CueFox started as one file: 225 kilobytes of hand-written HTML with all the markup, styling and animation in a single document. Moving to a component-based build meant splitting it into around 160 files.

The risk in that kind of port is not that it breaks loudly. It is that something shifts by four pixels on one breakpoint and nobody notices for three months.

So the original file is still in the repository, and it is never regenerated.

How it works

At the start, before any edit, we captured the computed styles of about 120 selectors across six viewport widths from the original page. Not screenshots. Actual resolved values: widths, heights, colours, letter-spacing, transform origins, bounding boxes.

Every build re-captures the same selectors from the new output and compares. Roughly 50,000 values per run.

The critical rule: the baseline is never re-captured. It is easy to add a “re-baseline” command, and the moment you have one, the response to a failing check becomes running it. The reference has to be immovable or it is not a reference.

Deliberate changes are recorded, not absorbed

Of course the design does change on purpose. When it does, each individual difference gets written into a file with the old value, the new value, the viewport, and a one-line reason:

{
  "selector": ".hero-eyebrow",
  "prop": "letter-spacing",
  "viewport": 390,
  "base": "-3.8px",
  "actual": "-3.51px",
  "reason": "tracking converted to -.065em; collapses 5 declarations into 1"
}

The comparison subtracts approved differences and still fails on anything else. Accepting one change does not blind the oracle to the next. And because each entry pins both the old and the new value, an approved difference that stops occurring is reported as stale, so the file prunes itself rather than accumulating dead entries forever.

We have 221 approved differences. Every one has a sentence explaining it.

What it has actually caught

Two things worth repeating, because neither was visible by eye.

A CSS minifier removed a declaration that looked redundant. The stylesheet sets a scale of 0.9 on some hero elements below 900 pixels and resets it to 1 below 700. The minifier deleted the reset as a redundant initial value. It is not redundant: without it those elements render ten per cent too small on every mobile viewport. Invisible unless you know what size they should be. Caught immediately by computed-style comparison.

A footer element was swallowing clicks. A large decorative wordmark is pulled up over the footer links by a negative margin, intercepting pointer events aimed at the links beneath it. That one was caught by a behaviour test rather than the oracle, and it had been there since the original file.

The cost

Honestly: it is annoying. When you change a headline, forty numbers move, and each has to be recorded. It slows down copy edits in a way that feels disproportionate.

We keep it because the alternative is not “faster edits”. The alternative is not knowing whether the site still looks the way it was designed, and finding out from a customer.