The full height hero check: size the hero to its content, not the screen

What goes wrong with a full-screen hero

The idea is understandable: a big opening screen feels like a poster. In practice it rarely helps the visitor.

• Phones measure the screen generously. On mobile browsers, 100vh is usually the height with the address bar and toolbars hidden. While they're showing, a hero set to that height runs off the bottom, so the button or the last line of the headline can sit just out of view.
• It hides that there's more. When the hero fills the screen exactly, nothing of the next section peeks in, and some visitors never scroll. A sliver of the following content is the simplest scroll cue there is.
• Short content gets padded with nothing. A headline and one sentence stretched over a full laptop screen leaves a large empty band, which reads as unfinished rather than bold.
• Landscape and short screens suffer most. On a phone turned sideways, a full-height hero can be taller than the text inside it can usefully fill, or too short for it, depending on the rule.

The 100vh on mobile guide covers the viewport units in more detail.

What the full height hero check matches

The Critic reads the page's stylesheet and fails the page if the rule for the .hero class contains 100vh. Height, minimum height and a calculation such as calc(100vh - 64px) all count, because each contains the unit. Some things pass:

So the check is precise about one common pattern and blind to others. It fits Anticode's own pages, whose hero always uses the .hero class, better than it would fit an arbitrary site.

What sizing to content means

A hero sized to content is as tall as what's in it, plus breathing room. On design-engine pages the hero has no height set at all. Its padding grows with the width of the screen, between about 56 and 128 pixels above the content and a little less below, so a phone gets a compact opening and a wide monitor gets more air. The headline, the line under it, the buttons and the key facts decide the rest. On most screens the top of the next section shows, which tells people to keep going.

The one tall hero

Luxury's full-width photo hero is deliberately tall, and it's handled differently. Its height is set on an extra class rather than on .hero itself, so this check doesn't read it, and it's bounded: a minimum of 560 pixels, a maximum of 920, and in between a share of the small viewport height (the height with the browser's toolbars showing), so it neither runs under the toolbar on a phone nor towers on a tall monitor. The headline and buttons sit at the bottom of the photo, where they're seen first. See the Luxury design system.

Fixing a failure

1. Remove the 100vh height or minimum height from the hero rule.
2. Give the hero vertical padding instead, ideally scaled with clamp() so it grows between a sensible minimum and maximum.
3. If you really want a tall opening, bound it: use the small viewport unit (svh) with a maximum, and keep the key line and button near the top of what's visible.
4. Check on a real phone with the address bar showing.

Limits

• Not a publishing block. It's a Critic check shown in the Report tab; the design gate doesn't enforce it.
• Text rule. It doesn't measure the rendered hero, so a hero made tall by a huge image or extra spacing passes.
• Pages only. Model-written apps get a headless-browser self-review at phone and laptop widths when it's available, rather than this rule.

Questions people ask

Should a hero section be full screen?

Usually not. A hero sized to its content, with part of the next section visible, gets more people to scroll and avoids being cut off on phones.

Does 100svh pass the check?

Yes. The check only looks for 100vh. The small viewport unit avoids the toolbar problem, but bound it with a maximum.

Will the hero check stop me publishing?

No. It's reported in the Report tab, not enforced by the design gate.