Changelog

Kolofon · 3 September 2026

0.11.15 — a splash screen, and spacing measured by window height

8:30 — a phone laid on its side and a page that looks empty

0.11.15 — a splash screen, and spacing measured by window height

Text: Kolofon

The spacing above the content was written as two values chosen by a width breakpoint: one for phones, another from desktop up. It looked sensible and bothered nobody for months. The question, though, was asked about the wrong thing.

A phone laid on its side has roughly four hundred pixels of height. The header eats a hundred and fifty-six of them, the spacing another ninety-six — and on a series page not a single item of the list fits any more. The reader sees the site name, the navigation, and nothing else. Worse: two entirely different series then look the same, because all that shows is what they have in common. The page does not look collapsed. It looks broken.

A width breakpoint could never catch this, because at that moment the width is generous. It is the height that is small. So the spacing is now computed from the height of the window: a floor, a value tied to the window, and a ceiling. On a phone held upright it comes out at eighty-nine pixels instead of the previous ninety-six, which is effectively the same. On a monitor the ceiling trims it to a hundred and twenty-eight, which is exactly what it was. It shrinks only where it was wrong.

The unit is svh, the smallest viewport a mobile browser reports — the one with the address bar extended. That way the spacing does not jump when the bar retracts during scrolling. The fallback for browsers that do not know svh had to go into a separate conditional block: the minifier drops an earlier declaration of the same property, so written the ordinary way it simply did not survive the build.

The second half of this release belongs to a different order of things. An instance can now show a splash layer: its own mark on the colour from the manifest, then a crossfade into the content. An installed application gets such a screen from the operating system; the website was getting one from nowhere.

The splash is not a component in the ordinary sense, and could not have been one. Had it waited for hydration it would have appeared only once the page was visible anyway — a flash of content, a cover, an uncover. The opposite of the intent. The decision to show it is therefore taken in an inline script in the document head, before first paint, and React supplies only the layer and the rules.

Everything about it is built to do nothing by default. The layer is invisible until the script uncovers it, so a reader without JavaScript simply sees the content. An instance without a mark shows nothing at all, because a splash with nothing on it would be pure delay. A request for reduced motion switches the whole thing off. The layer leaves the moment the fonts are ready — precisely when the typeface swaps from its fallback and the page shifts anyway — with a floor so it cannot flicker like a fault, and a hard ceiling so missing fonts cannot leave a blank page.

The lesson is the same in both halves. It is worth checking whether the question asked in the code is about the dimension that actually hurts.