Keep the end-card button above a declared bottom inset

An end card may look centred while its button overlaps a reserved screen area. This fixture makes the bottom inset part of the layout calculation instead of decorative padding added afterwards.

This edition is a laboratory fixture. Node and the companion HTML page execute the authored functions against synthetic cases. No physical device panel was run, no ad network reviewed the build, and no campaign result is inferred from a passing test.

What the documentation actually supplies

MDN: safe area is the governing reference for the browser primitive. MDN's env documentation describes safe-area inset values as distances defining a rectangle in which content is not cut off by the display or relevant browser features. Actual values must be obtained in the real rendering context. The fixture policy around that primitive is ours.

The failure the fixture isolates

The laboratory receives viewport height, bottom inset, button height and margin. The corrected branch subtracts all three constraints before placing the button. The broken branch ignores the inset. Inputs are synthetic; the fixture does not claim to detect a real notch, keyboard or host overlay from Node.

The broken branch is retained so a producer can see the exact mistake, not only the repaired output.

All 3 fixed-branch cases matched the spec when executed in Node on 19 September 2026.

What a pass does not prove

The expected value is the button's top coordinate, not a visual approval. A correct top value cannot prevent a parent container from clipping the button or a host overlay from covering it. The useful invariant is that the declared button rectangle stays above the declared reserved area.

Untested cells in this edition: physical devices, host SDKs, network packaging limits, store-opening callbacks, and campaign performance. Those remain empty on purpose.

Next check on a real build

In a real build, inspect computed safe-area values and host-specific overlay requirements separately. Resize and rotate while the end card is open, then check the full tappable rectangle. Avoid assuming the inset remains constant merely because the content design has a fixed aspect ratio.

Open the runnable fixture to re-execute the cases in a browser. Download the case record to keep inputs, expectations and limits with a QA ticket.

Background in the archive: Playable ad device testing matrix and Playable spec sheet before you build. Those guides describe practice; they are not a substitute for this fixture and this check does not recertify their every claim.