The news list on my own homepage rendered as 6,164 pixels of empty background. The markup was fine. The rows were in the HTML, the links worked if you typed the URL, and the block sat at opacity zero at every scroll position on the page.
Every block on the site marked .reveal starts hidden. A class goes onto the html element synchronously in the head so the stylesheet can hide them before first paint, and an IntersectionObserver adds the class that brings each one back. The observer was configured with a threshold of 0.12 and a rootMargin of "0px 0px -8% 0px".
A threshold is a fraction of the element, not of the screen. For a block taller than the viewport, the most of itself it can ever put on screen at once is the viewport height divided by the block height. The bottom margin trims eight per cent off the root, so the usable figure is 0.92 times the window. On my 772-pixel window that is 710 pixels. 710 over 6,164 is 11.5 per cent. The observer was waiting for 12.
That condition has no solution on that screen. Scrolling changes which part of the block is showing, never how much of it fits.
The margin thinned one row a day
The teaser grew by one row every time the noon job published a brief, and nothing trimmed it. Fifteen rows on 31 July. Twenty-five on 11 August. Thirty-six on 23 August. Each row is about 171 pixels.
At fifteen rows the block could put 27.6 per cent of itself on screen and revealed instantly. At thirty rows it was down to 13.8. At thirty-four, 12.2. The thirty-fifth row was committed at 12:18 on 22 August with that morning's brief, and took it to 11.9.
No commit touched the observer, the stylesheet or the threshold in that window. A daily publishing job walked a configuration value past its own limit one row at a time, and every individual commit was correct.
It still worked on a bigger screen
At a 900-pixel window the same block clears 13.4 per cent and reveals normally. The failure depended on window height, and the small window was the one that showed it. Anyone opening the page on a large display would have found it fine and said so.
The instrument returned the same answer either way
I could not test it. Both browser surfaces available to me exposed background tabs only, and document.visibilityState read hidden in both. Chrome does not call requestAnimationFrame when a page is in the background, which its own developer blog states plainly and MDN records as behaviour across most browsers. I attached a raw IntersectionObserver inside the page's own main world and it fired zero times in either surface.
Zero is also what a genuinely broken page returns. The harness produced the failing reading whether the site was healthy or not, so nothing it told me about reveal behaviour counted as evidence. Screenshots still render in a hidden tab, and that is what makes it convincing. A blank screenshot looks like a photograph of the bug. I passed one on as firmer proof than it was and had to walk it back an hour later.
What settled it was 710 over 6,164 on one side and my own screen on the other. Neither of those needed the harness, and I reached for the harness first.
The fix, and the number still sitting in the file
Two changes. Blocks taller than the root now reveal on entry, with the observer given a threshold array of [0, 0.12] so an entry callback exists to act on. And the teaser is cut from thirty-six rows to six. The homepage went from 15,840 pixels to 11,138.
The first change is the durable one. The second is a row count that is right today, sitting in a file a daily job writes to.
The 0.12 went into the site's script on 19 June, in a commit about hero animation and scroll-spy. That day the news block held one row. The number was still there, untouched, on 23 August, when the block held thirty-six.
Tomorrow around 12:20 the noon job writes the next brief into that list. The figure that decides whether the block can ever appear is 0.92 times the window height over the block height, and nothing in the build computes it. That check is the next thing I owe this site.