Halden

The Halden home page does not scroll

5 September 2026

Halden's home page is one viewport and it does not move. A photograph of a black door on a Marylebone street, the name of the house, and one way in. There is nothing below the fold because there is no fold.

The Halden home page filling a single browser window: the name in white serif capitals over the word Marylebone, the line A private house in Marylebone, and an ENTER link with a thin gold rule under it, all centred on a dimmed photograph of the black front door of number 18 behind iron railings. — The whole of the Halden home page, at the size it is meant to be seen. There is no second screen beneath this one.

That is normally a bad idea. A page that refuses to scroll breaks the first thing a visitor tries, and on a phone it is the difference between a site that works and a site that appears broken. It is worth doing only when the refusal is itself the content.

Halden is a private house. The whole proposition is that most of it is not shown to you. A conventional home page would have argued the opposite case in its structure while the copy claimed discretion: hero image, benefit columns, a testimonial, a footer full of links. The layout would have been the more honest of the two, and it would have been wrong.

So the page holds a single frame. The door is photographed straight on, at roughly the scale it would be if you were standing in front of it, and the only interactive element is the way through.

The mechanics are simple. The care is all in the failure modes. A threshold-lock class goes on both html and body, setting height to 100dvh with overflow hidden and overscroll-behavior none. Using dvh rather than vh matters here: on iOS the address bar collapses as you scroll, so 100vh is taller than the viewport actually showing at rest. A vh-locked page clips its own content on exactly the device most likely to see it.

The class is added by the component that owns the page and removed when that component unmounts. This sounds obvious and it is the part that breaks. Lock the document from one page, forget to release it again on navigation, and every subsequent page on the site is unscrollable. The bug does not appear until someone clicks through, which is well after the point where anyone is still looking at the home page.

The Halden house page at the top of its sequence: the title The House set in serif on cream, above a full-width photograph of the entrance hall where a stone staircase curves up past a tall window over a black and white chequerboard floor. No navigation bar sits above the title. — The house page, one click past the threshold. Everything beyond the home page scrolls normally, which is what the release on unmount is protecting.

The entrance sequence is gated on prefers-reduced-motion. Under that setting the timeline is never built at all, rather than played and then cancelled, so the frame is simply present and opaque from the first paint. A locked viewport and an animation a visitor cannot stop would be an unpleasant combination.

What the page gives up is measurable. There is no room for a second message, no space for proof, and no path for a visitor who wanted to browse rather than commit. Halden pays all of that deliberately, because the alternative was a page that said discreet in a layout that shouted.

One detail worth stating plainly: the lock is applied in an effect rather than written into the markup, so a visitor arriving without JavaScript gets a page that scrolls normally. That is the correct way for this to fail, and it is worth checking rather than assuming.

The rule that came out of it: a locked viewport earns its place only when scrolling would contradict the thing being sold. That is rare. It has been true once across three projects.