Intersection Observer v2

[BearCooder]

Description

This is a resubmission of the Intersection Observer v2 from last year Interop and previous one: #441 & #173.

Intersection Observer v2 introduces the concept of tracking the actual "visibility" of a target element as a human being would define it. By setting an option in the IntersectionObserver constructor, intersecting IntersectionObserverEntry instances will then contain a new boolean field named isVisible. A true value for isVisible is a strong guarantee from the underlying implementation that the target element is completely unoccluded by other content and has no visual effects applied that would alter or distort its display on screen. In contrast, a false value means that the implementation cannot make that guarantee.

An important detail of the spec is that the implementation is permitted to report false negatives (that is, setting isVisible to false even when the target element is completely visible and unmodified). For performance or other reasons, browsers limit themselves to working with bounding boxes and rectilinear geometry; they don't try to achieve pixel-perfect results for modifications like border-radius.

That said, false positives are not permitted under any circumstances (that is, setting isVisible to true when the target element is not completely visible and unmodified).

The IntersectionObserver constructor now takes two additional configuration properties: delay and trackVisibility. The delay is a number indicating the minimum delay in milliseconds between notifications from the observer for a given target. The trackVisibility is a boolean indicating whether the observer will track changes in a target's visibility.

This information is from the following source

Even on chrome with support it is not perfect and there are bugs according to wpt.

Specification

https://w3c.github.io/IntersectionObserver/

Additional Signals

Tests

https://wpt.fyi/results/intersection-observer/v2?label=master&label=experimental&product=chrome&product=firefox&product=safari&aligned&view=subtest

Standards Positions

• Blink intent to Implementing: https://groups.google.com/a/chromium.org/g/blink-dev/c/tudxAHN9-AY/m/vz91o_aNDwAJ?pli=1

• Mozilla positive: IntersectionObserver V2: Detecting occlusion and visual effects mozilla/standards-positions#109 (comment)

• WebKit undecided: IntersectionObserver V2: Detecting occlusion and visual effects WebKit/standards-positions#416

Mozilla has taken a positive standards position, and the V2 feature set has been merged into the spec.

Existing Usage

• Chrome's usecounter is at more than 8% of pageloads (https://chromestatus.com/metrics/feature/timeline/popularity/3051) which indicates developer interest in this feature as it is steadily growing. Cross browser compatibility would even further speed up the adoption.

• In the Survey, "Intersection Observer" was selected by ~15% of survey takers

• example implementation from Chrome: https://trick-ad-click.glitch.me/

And thank you @szager-chromium for the update on the spec in the thread of the last proposal!

[wpt-interop]

Thank you for proposing Intersection Observer v2 for inclusion in Interop 2025.

We wanted to let you know that this proposal was not selected to be part of Interop this year.

On behalf of the entire Interop team, thank you for submitting this proposal for consideration. We got many more proposals than we could include in this year's project, necessitating some difficult choices. Please note this should not be taken as a comment on the technology as a whole, or our willingness to consider it for Interop in the future. We appreciate the work you put into your proposal, and would welcome your participation in future rounds of Interop.

For an overview of our process, see proposal selection. Thank you again for contributing to Interop 2025.

Posted on behalf of the Interop team.