Problem
On the landing page, the desktop footer sits just below the initial viewport on common short-height displays, so users must scroll slightly before they can see it. The page feels longer than its single-document hero composition requires.
Current context
The behavior comes from the desktop height rules in app/(landing)/_components/landing.module.css:
.page has min-height: 100vh.
- At widths of 1024px and above,
.main has min-height: calc(100vh - 48px).
- The desktop footer has a fixed height of 48px.
- At widths of 1024px and above and heights of 820px or below,
.main is overridden to min-height: 772px.
The short-viewport override therefore forces the document to be at least 772px + 48px = 820px tall. At a 768px-high viewport, the footer is necessarily about 52px below the fold even though the 499px hero itself can fit.
Other relevant constraints:
- The desktop header is fixed at 64px.
- The hero is vertically centered and translated upward by 20px.
- The code surface is intentionally fixed at 408 × 499px on desktop.
- The public-page design system requires a 48px desktop/tablet footer.
- Mobile is intentionally a longer stacked document with a 600px code surface and a 144px footer; the initial-viewport expectation should not be applied blindly to mobile.
Expected behavior
At standard browser zoom on desktop layouts, the full 48px footer should be visible in the initial viewport whenever the documented hero composition fits. Short desktop viewports should not gain extra document height solely because of a fixed minimum-height floor.
Investigation direction
- Revisit or remove the
min-height: 772px short-viewport override.
- Prefer a viewport-aware layout using
dvh/vh and the existing header/footer tokens.
- If short viewports need special treatment, adjust hero alignment or vertical spacing instead of extending the document beyond the viewport.
- Review whether
.page { overflow: hidden; } should be narrowed to horizontal overflow so zoom, focus outlines, and legitimate vertical content are not clipped.
- Preserve the measured SST-derived desktop geometry and the intentionally stacked mobile layout.
Acceptance criteria
- The footer is fully visible without vertical scrolling at standard zoom for representative desktop viewports, including 1440×900, 1440×800, 1366×768, 1280×720, and 1024×768.
- The hero does not overlap the fixed header or footer at those sizes.
- The 408 × 499px desktop code surface and 48px desktop/tablet footer remain visually consistent with
docs/design.md.
- Tablet and mobile layouts retain their intended content order and may scroll naturally.
- No horizontal document overflow, clipped focus state, or text truncation is introduced.
- Add or update responsive visual regression coverage for the affected viewport heights.
Problem
On the landing page, the desktop footer sits just below the initial viewport on common short-height displays, so users must scroll slightly before they can see it. The page feels longer than its single-document hero composition requires.
Current context
The behavior comes from the desktop height rules in
app/(landing)/_components/landing.module.css:.pagehasmin-height: 100vh..mainhasmin-height: calc(100vh - 48px)..mainis overridden tomin-height: 772px.The short-viewport override therefore forces the document to be at least
772px + 48px = 820pxtall. At a 768px-high viewport, the footer is necessarily about 52px below the fold even though the 499px hero itself can fit.Other relevant constraints:
Expected behavior
At standard browser zoom on desktop layouts, the full 48px footer should be visible in the initial viewport whenever the documented hero composition fits. Short desktop viewports should not gain extra document height solely because of a fixed minimum-height floor.
Investigation direction
min-height: 772pxshort-viewport override.dvh/vhand the existing header/footer tokens..page { overflow: hidden; }should be narrowed to horizontal overflow so zoom, focus outlines, and legitimate vertical content are not clipped.Acceptance criteria
docs/design.md.