Caniuse: IntersectionObserver

[arturparkhisenko]

Spec: https://github.com/WICG/IntersectionObserver/
Mdn: https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API

Chrome: 51+ https://www.chromestatus.com/feature/5695342691483648
Opera: 38+
Edge: feature request link and Roadmap link Status: In Development
FireFox: https://bugzilla.mozilla.org/show_bug.cgi?id=1243846
WebKit(Safari): https://webkit.org/status/#specification-intersection-observer

[orzage]

+1

[ghost]

+1

[jrstanley]

FireFox bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1243846

[cvrebert]

+1

[jrstanley]

+1

[ghost]

Under Consideration with Medium priority by Microsoft: https://developer.microsoft.com/en-us/microsoft-edge/platform/status/intersectionobserver

[nullbert]

+1

[jhiggins-thrillist]

+1

[okor]

+1

[rjgotten]

Something to make mention of:

Chrome's implementation is fundamentally broken, atleast up to the current 53.0.2783.2 dev-m version. The way it observes threshold changes and enqueus change records does not adher to spec.

According to spec, a change record is supposed to be enqueued when the active threshold changes.
The active threshold is computed as follows:

• when intersection ratio is 0, the threshold is 0
• when intersection ratio is 1, the threshold is the length of the thresholds array (i.e. one index greater than the number of thresholds)
• otherwise, the threshold is the index of the first threshold with a value greater than the intersection ratio.

(Source: Draft spec, section 3.2.5 - algorithm step 3.2.8)

For the default { threshold : [0]} setting, Chrome currently already enqueues a change record when the intersectionRatio is exactly 0. This makes it impossible to use a intersectionRatio > 0 condition to reliably test if an element just became visible or invisible. The case where there is an intersection consisting of a coincident edge can not be discriminated from the case where there is no intersection, since in both cases the intersection ratio will be 0.

[cvrebert]

@rjgotten Is there a Chrome bug report for that?

[cvrebert]

@rjgotten I filed https://crbug.com/646202 based on your description. If you have further details (or a testcase), it would be great if you could post them on that bug.

[cvrebert]

WebKit: In Development: https://webkit.org/status/#specification-intersection-observer

[mkurz]

Edge: Intersection Observer is In Development - https://github.com/MicrosoftEdge/Status/pull/464

[cvrebert]

@rjgotten Apparently that's working as intended; see https://bugs.chromium.org/p/chromium/issues/detail?id=646202#c5

[rjgotten]

Apparently that's working as intended

Yeah; this is a case of Google amending their spec to conform to their existing (broken) implementation.
Note also: https://github.com/WICG/IntersectionObserver/issues/156

(Could be fun if Mozilla and Microsoft are going to have implementations based on the currently authored and out-of-date spec document...)

[lingtalfi]

+1

[rjgotten]

@cvrebert

After some further digging, I'm inclined to believe that this is not working as intended at all, and that the engineer replying in that tracker issue is doing little other than offering a shoddy workaround wrapped as an end-solution.

If the use of the Number.MIN_VALUE value to detect if an element is intersecting the target bounds for _any_ amount of non-zero intersection, would indeed by design; and if it should indeed be used instead of the 0 value that Google's own spec states, then _why_ is the default thresholds value in Chrome's implementation still a known-broken value of [0]?

(Yeah; check that for yourself: new IntersectionObserver(function(){}).thresholds should return [0] still...)

[AdamModus]

+1

[Fyrd]

Now available at http://caniuse.com/#feat=intersectionobserver