Require both intersection and document visibility before advancing

Editorial collage hero: playable-bench-viewability-gate

Require both intersection and document visibility before advancing. A runnable teaching fixture with synthetic cases, a broken branch, and explicit untested cells.

An element can remain geometrically inside a viewport while its document is hidden. This fixture checks a deliberately simple activity gate that requires both conditions.

This article 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: viewability gate is the governing reference for the browser primitive. MDN describes Intersection Observer as asynchronously observing a target's intersection with an ancestor or viewport. Intersection is a geometric signal; this fixture does not interpret it as a certified impression or billable viewability event. The fixture policy around that primitive is ours.

The failure the fixture isolates

The laboratory uses an illustrative intersection threshold of one half and a separate visible flag. The broken branch checks the ratio alone. The corrected branch requires both signals, showing why a single convenient visibility-like number should not silently control the whole playable lifecycle.

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

CaseInputExpected (fixed)Broken output
intersecting hidden document`{"ratio":1,"visible":false}``false``true`
visible above threshold`{"ratio":0.8,"visible":true}``true``true`
visible below threshold`{"ratio":0.2,"visible":true}``false``false`

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

What a pass does not prove

The threshold is a teaching choice, not an ad-network rule. A passing function demonstrates Boolean gating for supplied inputs, not a physical visibility observation. Occlusion, host lifecycle events and the measurement definition used by a network remain outside this test.

Untested cells in this article: 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 an actual integration, document which signals are authoritative for activity and which are only diagnostic. Feed them into one state transition rather than allowing several listeners to start and stop independent loops. Record why the state changed so an apparently frozen playable can be traced to its input conditions.

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.

Related posts

When midcore playables should stay out of a network: kill criteria

media buying

playable ads

·

1 min read

When midcore playables should stay out of a network: kill criteria

Rewarded placement map: session minute versus ad load

media buying

playable ads

·

1 min read

Rewarded placement map: session minute versus ad load

Midcore playable: one complete loop before CTA

creative strategy

playable ads

·

1 min read

Midcore playable: one complete loop before CTA