Checking a skin

The failures above have one thing in common: each was invisible in the way the skin was being looked at.

Click every control at least once, for real. The theme switch, the menu button on a phone width, an image that opens the lightbox, the search field, the back-to-top button, and the share row under a post -- its Mastodon button opens a question with an input and an error line, and three of the controls are hidden until a script shows them. Setting state directly -- flipping a data attribute to photograph the dark theme -- proves the CSS and proves nothing about whether the control is reachable.

Measure at three widths, not one. A wide desktop, something around the breakpoint, and a phone. The engine's own reflow happens at 700px, so a skin that has never been seen between 700px and its own breakpoint has an untested range.

Look at both schemes. A skin that only defines colours for one of them inherits the other from the palette, which is usually fine and occasionally a white-on-white surprise.

Three traps in browser tooling, all of which have cost an afternoon here:

• A hidden preview panel reports innerWidth: 0, and every width and height measured through it is then nonsense -- text wrapping to a zero-width column, cards ten thousand pixels tall. Check innerWidth before believing any layout measurement.
• A screenshot does not wait for images to decode. A page photographed the instant it loads can show empty frames that are fine a moment later.
• The preview cache outlives a reload. A different origin (127.0.0.1 instead of localhost) gets you one clean look; after that, version the stylesheet's address in the built page.
• :focus and :focus-visible do not match in a headless browser unless the page is told it has focus -- a window nobody is looking at has none. A focus ring that "does not work" there may be fine, and one that was never drawn may pass; turn focus emulation on before judging either, and then press Tab for real once.

And one in the engine's own tooling. ./blog.sh rebuild does not wait for a run that is already going -- a scheduled publish, a sidebar refresh. It says so, marks the site as owing a deploy and leaves; the next scheduled run sends what you changed. So "I rebuilt and the site looks the same" is sometimes the truth for another minute. Before deciding a rule does not work, compare the stylesheet the live site serves with the one you wrote:

curl -s https://YOUR-BLOG/assets/css/skin.css | shasum -a 256
shasum -a 256 assets/css/skin.css