Fit the whole playable stage inside a narrow viewport
A teaching fixture that separates min-ratio containment from max-ratio crop using declared design and viewport sizes, grounded in MDN layout-viewport definitions.
A playable can fill a narrow slot and still hide the control that makes it playable. This laboratory fixture shows the difference between containing a declared stage and cropping it, using synthetic design and viewport sizes. It is for playable engineers and producers who need a reproducible geometry check before a device panel or network preview.
Coordinate context, not a network size rule
MDN defines Window.innerWidth as the interior width of the window’s layout viewport in pixels, and points to innerHeight for the corresponding height. That supplies a coordinate context for teaching layout math. It is not a network creative-size rule and does not identify an advertising slot. MDN: Window.innerWidth (last modified 21 August 2026; accessed 19 September 2026).
In a live build, measure the host container the network supplies. Do not assume the browser window is the ad slot.
Broken branch versus fixed branch
Both branches take the same inputs: viewport width and height, then design width and height.
- Broken (max-ratio): scale by the larger of width-ratio and height-ratio. The stage fills both axes by cropping overflow.
- Fixed (min-ratio): scale by the smaller ratio. The complete stage remains visible; empty space (letterboxing) is an explicit consequence, not mandated art direction.
A pass means neither scaled dimension exceeds the supplied viewport. It does not prove label legibility or tap-target size. Those need a rendered review at the actual dimensions and a separate interaction check.
Worked synthetic cases
Inputs and expected fixed outputs are laboratory declarations. They were recomputed from the published formulas; no physical device-lab run was executed.
| Case | Viewport (w×h) | Design (w×h) | Fixed scale result | Broken scale result | Fits under fixed? |
|---|---|---|---|---|---|
| Narrow portrait | 320×480 | 360×640 | 270×480 | 320×569 (height overflow) | Yes |
| Landscape | 640×360 | 360×640 | 203×360 | 640×1138 (height overflow) | Yes |
| Same ratio | 360×640 | 360×640 | 360×640 | 360×640 | Yes (both agree) |
On the two mismatched-ratio cases, the broken branch overflows height while filling width. When ratios match, both branches agree and neither overflows.
Artifact and untested runtime cells
Download the fixture cases, formulas and untested runtime matrix. The CSV records synthetic inputs, both branches, pass criteria and failure notes. Runtime rows for desktop Chrome, iPhone Safari ad slots, Android WebView hosts and network preview tools remain marked untested: a browser pass on declared sizes is not a device panel, and this article does not claim network approval, analytics delivery or campaign performance.
Operator follow-up
Change the declared viewport and design sizes, then check the fit rectangle before evaluating decoration. Keep hit coordinates in the same layout space as the stage. Treat letterboxing as a deliberate geometric trade-off to review with creative, not as proof that cropping would have been better for completion rate.
Related reading: Playable spec sheet before you build and Fake difficulty, real difficulty in playable design. Those links provide context; this bench does not independently verify their full contents.
