Why full-screen sections are harder than writing 100vh

A full-screen hero sounds like a one-line CSS decision:

min-height: 100vh;

On a desktop browser, that may be enough. On a phone, the browser itself moves. Address bars collapse. Toolbars expand. The visible viewport changes as the user scrolls. Keyboard appearance changes available height. Different browsers interpret viewport units differently. That is why a visually simple "fill the screen" requirement can create surprisingly technical bugs.

The problem with traditional 100vh

Historically, 100vh on mobile often represented a viewport larger than the currently visible area. That can put content underneath browser controls or create a section that feels too tall. The CSS is mathematically correct according to one viewport definition and visually wrong according to the user.

Modern viewport units help

Newer CSS provides units such as svh, lvh, and dvh. The small viewport unit is useful when we want a stable height that accounts for mobile browser chrome. Dynamic viewport height can follow changes as the visible viewport expands and contracts. We choose based on the behavior the section needs.

Our repos use layered fallbacks

One production build defines a tall page hero with both a traditional viewport calculation and a modern small-viewport calculation:

min-height: calc(100vh - 66px);
min-height: max(520px, calc(100svh - 66px));

On larger screens, the navigation offset changes and the minimum safe height increases. This is not decorative complexity. It solves two separate problems. The viewport calculation makes the section feel intentionally full-screen. The fixed minimum keeps the design from collapsing into an awkwardly short hero on unusual landscape or browser configurations.

Navigation height is part of the equation

A site with a fixed header does not really have the full viewport available. If the hero uses 100vh while an 80-pixel navigation sits on top of it, the visible section becomes taller than the screen. Subtracting the known navigation height makes the intended composition explicit.

This is one reason we centralize header sizing variables where practical.

Mobile Safari exposes animation mistakes too

Viewport resizing can interact badly with opacity and transform animations. On one site, the safer mobile behavior was to disable the hero reveal on touch-first devices rather than allowing content to flicker or appear late while browser chrome changed the viewport. That is an example of a broader rule: responsive behavior includes browser behavior, not just screen width.

Why we use minimum height instead of fixed height

A fixed height can clip content. Headlines wrap differently across devices. Accessibility font scaling can increase text size. Translation can make copy longer. Small laptop screens can have unusual aspect ratios. min-height lets the section reach the intended visual size while still growing when the content requires it.

That is much safer for real content.

Full-screen design should not become a content trap

A 100vh section is a composition choice, not an excuse to force every paragraph into one screen. If the content needs more room, the section should grow. We use full-height treatment most successfully for strong title sections, hero compositions, and visual transitions where the amount of content is controlled.

Long documentation and article content should flow naturally.

Test width and height together

Responsive testing often focuses only on width breakpoints. Height matters too. A 390 by 844 phone and a 844 by 390 phone have the same hardware and completely different composition constraints. Small laptops can be wide but short. Browser toolbars can reduce the usable space without changing the CSS width.

This is why we test real combinations instead of assuming "mobile" is one viewport.

Why this belongs in performance documentation

Layout instability is a performance problem from the user's perspective. If a hero jumps as browser chrome changes, if content appears late because an animation restarts, or if the first section forces unnecessary scrolling because the height calculation is wrong, the page feels slower and less controlled.

Performance is not only milliseconds. It is also whether the interface settles quickly into a stable, predictable layout. The modern viewport tools let us make that stability intentional.