Investigate rendering across real-world viewport sizes, display scaling and pixel densities

Problem

Nobody has systematically checked how the site renders across the displays people actually use. Manual testing hasn't turned up anything bad. But the layout keys several large changes off CSS pixel width, and some combinations of width, height and device pixel ratio have never been looked at. This issue covers investigating those combinations and measuring the results. Fixes go in follow-up issues, one per confirmed problem.

Background: what actually varies

Breakpoints, OS display scaling, browser zoom and retina all resolve to CSS pixels. A 1080p laptop at 150% scaling is a 1280px viewport; a MacBook Pro 14" is 1512px. Device pixel ratio (DPR) doesn't change layout at all; it only affects how sharp images are. So the matrix is CSS viewport (width × usable height) × DPR, not a list of monitor resolutions.

The breakpoints (xlarge 1680, large 1280, medium 980, small 736, xsmall 480, xxsmall 360) also change the root font size in base/_typography.scss, and that scales every rem value, including padding, inner width and headings:

Usable height is the viewport minus browser chrome, roughly 100–130px on desktop. A 1920×1080 display gives about 950px.

Suspected problems

These are inferred from reading the Sass and the image pipeline. None has been observed in a render yet.

1. Blurry full-width banners on anything above ~1100 device px wide. This is the strongest suspect. The five banner style2 sections (on engineer.html, engineer-ai.html, engineer-devops.html, engineer-firmware.html and leader.html) stretch images/brandi-redd-122054.jpg across the full viewport with object-fit: cover. The master is portrait (3456×4965). optimize-images.mjs limits the long edge to 1600px, so the deploy serves roughly 1114×1600. In a short, wide banner the width sets the scale: 1.7× upscale at 1920×1 DPR, about 2.7× on a MacBook Pro 14" (1512×2), and 3.4× at 4K. No page uses srcset.
2. A step change at 1680/1681px. The root font jumps from 18.7px to 24px (+29%) when the viewport grows by 3%. A MacBook Pro 16" (1728px) gets much larger type and padding than a 14" (1512px): the hero h1 becomes 84px and section padding 168px.
3. Full-height banners on short viewports. Three fullscreen banners use min-height: 100vh. At 1920×~950 with a 24px root, and at 1280×~600 or 1366×~650, the "Tell Me More" button may fall below the fold. Landscape phones have the same problem at about 400px tall.
4. Portrait desktop monitors get the portrait-orientation banner and spotlight rules that were written for tablets. That means stacked layouts with images 45–50vh tall, about 900px at 1080×1920.
5. Very wide viewports (2560, 3440, 3840). Content stays capped at 64rem (1536px), but full-width banners become wide, short strips, so the image is cropped heavily and upscaled further.
6. 50%-width spotlight images at 4K. index.html uses code-tilt-shift.jpg and sunset-friends.jpg, whose 2400px masters are served at 1600. At 3840px each half is 1920 device pixels, a 1.2× upscale. Minor.

Phones in portrait are expected to be fine: there is a viewport meta tag, every common phone width lands on xsmall, and the round style3 hero images (21rem) have enough pixels at DPR 3. Confirm it rather than assume it.

Approach

Render, then measure. Screenshots are for confirming what the measurements show; don't rely on eyeballing alone.

• Test the deployed build. Build _site/ the way static.yml does, with optimize-images.mjs applied. The repo keeps full-size masters, so a render of the repo tree looks sharper than production and hides problem 1.
• Viewports: the table above at each device's real DPR, plus phones at 360, 375, 390, 412 and 430 in both orientations. Use usable heights, not panel heights.
• Pages: at least index.html, engineer.html (it has both the style2 banner and the .items grids), one gallery page, and leader.html.
• Measure at each combination:
  • horizontal overflow (scrollWidth > clientWidth)
  • whether the primary banner button is inside the first viewport
  • for every image, naturalWidth against rendered CSS width × DPR, reporting anything upscaled
  • line length at the widest viewports
• Headless Chrome traps found while reviewing #145:
  • Chrome won't size a window below about 500px, so a narrow --window-size shows clipping that isn't there. Use a sized <iframe> or CDP device emulation.
  • The scroll-in fades leave off-screen content at opacity: 0 in a capture.
  • loading="lazy" images below the fold never decode, so force eager before measuring.
  • The Source Sans Pro font swap (#96) changes heights after first paint, so measure after document.fonts.ready.
  • Use --force-device-scale-factor for DPR.

Related issues

• #102 (site/ restructure and 4K source cap), in three ways:
  • Its 3840px long-edge cap would leave the portrait banner master 2673px wide, still short of the 3840 device pixels a 4K full-width banner needs. Any fix for problem 1, whether a landscape crop, a width-based limit for banner images, or srcset variants, has to agree with that cap policy.
  • A srcset fix would rewrite <img> tags on every page and change optimize-images.mjs from one output per image, written in place, to several variants. Both overlap the site/ move, so the fixes should be sequenced after #102 Part 1 or coordinated with it.
  • #102 needs "every image renders, checked on every page", and the harness built here could provide that check.
• #118 (no render or layout check in CI). This investigation is a natural prototype. A trimmed version of the matrix could become that check.
• #96 (font swap). It affects height measurements; see above.

Acceptance criteria

• Render and measurement harness committed, or its location recorded, so the matrix can be re-run
• Measurements recorded for every viewport, DPR and page combination above, run against a deploy-equivalent _site/
• Each of the six suspected problems marked confirmed (with evidence) or ruled out
• A follow-up issue filed for each confirmed problem, cross-referenced with #102 where the fix touches images or page markup
• No fixes in this issue

Build the deploy-equivalent _site/ using static.yml and optimize-images.mjs, then inspect the pages and styles named in the issue, including base/_typography.scss and the listed HTML pages. Start with the viewport/DPR matrix and measure overflow, banner-button visibility, font readiness, and image upscaling after loading completes. Done means the harness and measurements are recorded, all six suspicions are confirmed or ruled out, and follow-up issues are filed for confirmed problems.