CSS viewport units and safe areas: size panels around real browser chrome

How the rule works

A mobile case sheet needs to fit between the top and bottom of the usable viewport. A plain 100vh minimum can extend behind browser controls on some mobile browsers, so use a small-viewport baseline and a dvh unit when supported. Reserve safe-area padding where the device exposes an inset. Content may still grow beyond the viewport; min-block-size is safer than block-size for a form with validation messages or a keyboard. The sample is a layout guard, not a promise that the on-screen keyboard never covers a field. Test real mobile browser chrome, orientation changes, zoom, and a long error message. Keep the form scrollable if it grows past the available height.

.case-sheet {
  min-block-size: 100vh;
  min-block-size: 100svh;
  padding-block-end: 1rem;
  padding-block-end: max(1rem, env(safe-area-inset-bottom));
  overflow-y: auto;
}
@supports (min-block-size: 100dvh) {
  .case-sheet { min-block-size: 100dvh; }
}

Cost and verification

Changing viewport sizing may trigger relayout while browser chrome changes, so avoid coupling it to expensive animations or constantly measured script geometry. The small-viewport baseline is steadier but may leave unused space when controls retract. Choose based on the panel's task, then measure and test on devices your users actually have. The first padding declaration covers clients without env() support; max() keeps at least one rem where the inset is zero. Do not use a fixed height that clips focusable controls when translation or validation increases content height.

Common Mistakes

• Do not assume 100vh always equals visible mobile space.
• Do not set a fixed height on a form that can grow.
• Do not rely on safe-area padding to solve keyboard occlusion by itself.

Connected lessons

• Responsive CSS
• CSS media queries: change layout at a content failure point
• CSS overflow: contain long data without losing controls
• Responsive CSS: keep reading order and controls usable