Mobile Viewport Units
Use
svh,lvh, anddvhinstead of100vhfor mobile full-height surfaces because browser chrome changes the visible viewport after load.
The failure mode is simple: a hero, modal, or onboarding screen looks correct in DevTools, then gets clipped on a real phone because 100vh is calculated against a viewport that does not match the currently visible browser UI. Mobile browsers show and hide address bars, toolbars, and safe-area chrome while the user scrolls. Source: X/@vponamariov, 2026-03-12
Unit choice
| Unit | Meaning | Default use |
|---|---|---|
svh |
Small viewport height: browser UI visible. | First-load heroes, modals, dialogs, and surfaces that must not start clipped. |
lvh |
Large viewport height: browser UI hidden. | Decorative fullscreen backgrounds where extra height is acceptable. |
dvh |
Dynamic viewport height: updates as browser UI changes. | App shells and panels that should resize while the browser chrome appears or disappears. |
For agent-built UI, the default correction is: replace h-screen / height: 100vh with min-h-[100dvh] or an explicit svh/dvh choice based on the surface. svh is safer when content must fit on first paint; dvh is better when the surface should track chrome changes. Pair either with safe-area padding where bottom bars or notches matter.
Agent checklist
- Test mobile full-height sections on a real mobile viewport, not only desktop DevTools.
- Never use
h-screenfor critical first-viewport product surfaces. - Prefer
min-heightover fixedheightunless overflow is intentionally locked. - If the layout has a sticky footer, CTA, or modal action row, verify it remains reachable with browser chrome visible.
Timeline
- 2026-03-12 | @vponamariov published the mobile viewport-units thread explaining why
100vhclips mobile heroes and howsvh,lvh, anddvhmap to browser UI states; local artifact review confirmed the three-phone diagram. Source: X/@vponamariov, 2026-03-12