Check Responsive Layouts Across Sizes and Zoom

Responsive checking is a small matrix, not proof from one named device preset. Vary three independent dimensions:

• viewport width in CSS pixels
• page zoom
• content variant

Start from known conditions and use representative checks rather than every possible combination. If something looks suspicious, add focused checks around that condition. Record CSS pixels, not physical screen pixels.

On your computer, create one folder containing index.html and styles.css. Replace the contents of index.html with these three consecutive sections, in order. The native links point to real sections later in the same page.

Save both files and open index.html in your regular browser. Confirm that the stylesheet is applied, each navigation link reaches its section, and the page can scroll. Keep the initial content as Default and leave the CSS unchanged for now.

Before changing anything, create a note using these exact labels:

Browser/version
Viewport
Zoom mode and level
Content variant
Steps to reproduce
Expected
Actual
Responsible element/rule
Correction
Retest result

A responsive preview can set a precise viewport width in CSS pixels. Its display-fit scale only makes that preview fit on your screen; it does not change the page’s CSS layout like page zoom does.

For this width sweep, use 100% page zoom and the Default content variant. Record viewport dimensions in CSS pixels, not physical screen pixels. Keep the browser/version with your notes so another person can repeat the check.

Sample narrow, intermediate, and wide widths, then drag-resize slowly between them. A sampled width can look fine while a brief wrap, overlap, or horizontal overflow appears between samples.

At every stop, inspect card wrapping, gaps, clipping, overlap, and unexpected page-level horizontal scrolling. Vertical scrolling is normal. If a failure appears, note the first viewport width where it appears, plus the baseline conditions.

A 200% enlargement check asks a practical question: can people still read and use the page when text is much larger? A passing layout keeps every heading, link label, navigation control, and content area available. Extra vertical scrolling is normal; clipped text, overlap that hides a control, or missing content is not.

Use the Trail Guide page with the Default content variant. Keep the browser window and its viewport conditions recorded so that you can repeat a result.

Use the regular browser window for the primary check. Set page zoom to 200%, inspect the page, then reset it to 100% before trying another mode.

If your browser supports text-only zoom, set that mode to 200% as an additional check. It can affect the layout differently, so do not treat it as the same test or combine its result with page zoom.

Record the mode and level used. A preview's display-fit scale, operating-system magnification, and pinch magnification are not browser page zoom.

On your own computer, open index.html in a regular browser window using Default content. Record the browser/version and current viewport width and height in CSS px; mark either measurement as approximately if necessary.

1. Set page zoom to 200%.
2. Inspect headings, link labels, navigation, and content containers. Check for clipping, overlap, missing text, and controls that cannot be used.
3. Reset to 100%. If supported, repeat with text-only zoom at 200% and record it separately.

A zoom value does not guarantee that each font visibly enlarged as intended: viewport-dependent font formulas can counteract apparent growth. Judge what is actually rendered. Reset to 100% when finished.

Reflow is about the space available to ordinary page content, measured in CSS pixels—not physical screen pixels. Around 320 CSS px, prose, navigation, and cards should wrap or stack so that you can read each line without page-level horizontal scrolling. Vertical scrolling is normal.

Use two related checks:

• A direct 320 CSS px browser preview at 100% page zoom.
• A regular browser-window check at 400% page zoom.

Neither check replaces the other. The direct preview gives a controlled width; the zoom check shows how the page behaves when the effective viewport becomes narrow during enlargement.

For the zoom comparison, first establish and record a baseline in a regular browser window: for example, 1280 × 800 CSS px at 100% page zoom with the Default content variant. Keep that browser window the same size, then change only page zoom to 400%.

This is an approximation: a roughly 1280-CSS-pixel-wide viewport at 100% becomes approximately 320 CSS px wide at 400%. Do not describe the full physical screen as the viewport.

Docked developer tools reduce the available viewport. Close them, undock them, or record the actual available dimensions. If you cannot establish the baseline, run the direct 320 CSS px check and explicitly record that the equivalent 400% comparison was not established.

The Default Trail Guide page uses short labels and only three cards. It can look stable even when its layout will fail with realistic content.

A useful stress check changes one content factor at a time and repeats the same viewport width, page zoom, browser, and CSS. That way, an observed change has a clear cause. Do not change CSS during these checks; first collect evidence about what the content exposes.

Try isolated probes before combining them. After that, run the prescribed named variants: Long text and Extra cards.

Start each check from a saved Default version. Use 100% page zoom and compare each change at 320 CSS px and near the breakpoint: 767, 768, and 769 CSS px. Keep the browser/version, CSS, and viewport height as consistent as practical.

First, isolate the effects: test a longer first heading alone, restore Default, then test the unbroken reference alone. The prescribed Long text variant contains both edits, so use it after those isolated observations. For Extra cards, duplicate only the three existing card elements once. Do not duplicate the detail sections or any IDs; the copied links can still point to the original fragment destinations.

When you find page-level horizontal scrolling, do not begin by hiding overflow on the page. That can conceal essential content while leaving the responsible constraint in place.

First preserve the original reproduction. In your defect record, keep the Browser/version, Viewport, Zoom mode and level, Content variant, Steps to reproduce, Expected, and Actual fields. Include viewport height too, and write “approximately” if the measurement is estimated.

At the failing conditions—often the Long text variant at a narrow viewport width—open the element inspector. Select the element that extends beyond the viewport. Hover elements in the inspector to compare their box boundaries with the viewport, then inspect computed sizing and temporarily toggle one suspected declaration.

Use the inspector as a hypothesis test, not as a permanent editor. If disabling .card’s minimum width removes the oversized box, that rule is the first confirmed cause. If the card then fits but the reference still protrudes, select .card__reference and inspect its computed white-space value.

A reference with white-space: nowrap cannot use normal line wrapping. Override or replace that rule before testing overflow-wrap. Change one rule at a time. A developer-tools toggle is temporary: once it works, save the corresponding change in styles.css, refresh, and verify it again.

Replace the relevant existing declarations in styles.css only after confirming the corresponding causes locally.

CSS can change the visual sequence without changing either the HTML document order or the native keyboard focus order. Check all three as separate evidence:

• Visual sequence: where the cards appear on screen.
• Document order: the sequence of card elements in index.html.
• Keyboard focus order: the interactive controls reached with Tab.

At 767 CSS px, the one-column layout may make these sequences look identical. At 768 CSS px, a layout rule can expose a difference. Tab visits focusable controls such as links; it does not stop on every heading or paragraph.

Restore the Default variant before this check: use the original three cards once, the original first heading, and the original reference text. At 100% page zoom, compare 767 CSS px and 768 CSS px.

1. Inspect the card elements in index.html and note their source sequence.
2. At each width, note the rendered card sequence.
3. Keep the browser toolbar and developer tools out of focus. Click a noninteractive blank area of the rendered page, then press Tab until you trace the three card links. Use Shift+Tab to confirm the reverse route.

Record the card-link sequence separately from other links such as header or Help links. Do not infer document order from the wide visual grid.

Inspect this part of index.html. Its element sequence is the document order; CSS does not move these elements in the source.

Inspect the wide-layout rule in styles.css after completing the comparison. This rule changes rendered placement, not the HTML sequence or the browser's native Tab sequence.

Horizontal fit is not enough. A sticky header can cover a fragment destination or a newly focused card link at the top of the viewport. A fixed help link can cover content or focus near the bottom.

Check while scrolling and while using Tab and Shift+Tab. At high page zoom, the effective viewport becomes shorter as well as narrower, so an obstruction that is hard to notice at 100% may become obvious.

At the failing viewport width and page zoom, Tab through the native links from inside the page. Watch where the browser scrolls each link into view. Inspect both viewport edges, then follow a fragment link such as a card link or the help link and check its destination.

Do not treat a larger z-index, root-level overflow hiding, or clipping text as a fix. Those can conceal the symptom while leaving content or keyboard access obstructed.

Replace only the positioning portions of the existing rules. Keep their other visual declarations. In the existing wide-layout media query, add the positioning declarations shown here so pinned behavior is limited to wider conditions.

Use the regular browser window at the same size for the comparison. A viewport near 1280 CSS px wide at 100% page zoom becomes approximately 320 CSS px wide at 400% page zoom. Record the actual viewport height too, because reduced height can expose top or bottom obstruction.

After saving a confirmed correction, repeat Tab navigation, fragment-link navigation, and a scroll to the final page content. Vertical scrolling is expected; hidden focused controls are not.

A final regression pass starts with evidence, not a broad claim that the page is “responsive.” Reproduce the original failure using the same Browser/version, Viewport, Zoom mode and level, and Content variant. Confirm that the saved correction changes the observed result.

Then check representative neighboring conditions: a nearby viewport width, the layout on the other side of a breakpoint when relevant, and the interaction that was affected. This catches a correction that fixes one narrow case while creating a new problem elsewhere.

Run isolated checks before a combined stress check. For example, after recording a baseline, test Long text at 400% page zoom. Mark every check as observed pass, observed failure, or not checked. “Not checked” with a limitation is more useful than unsupported coverage.

Use this compact matrix to make the final pass explicit. Record the actual viewport height too; if a browser preview measurement is estimated, write “approximately.” A browser preview’s display-fit scale is not page zoom.

For a combined stress check, retain the recorded baseline. At 400% page zoom, a regular browser window that was 1280 CSS px wide at 100% is approximately 320 CSS px wide when the window size is unchanged.