TLDR: Using an Intersection Observer to observe position change of elements without listening to scroll events or continuous polling.

Demo:

https://ajk-essential.github.io/Position-Observer/

Github repo:

https://github.com/AJK-Essential/Position-Observer

Motivation:

Traditionally to observe when an element moves within a viewport, we have to rely on listening to scroll events of the parent elements of the HTML element or use continuous polling methods like using requestanimationframe.

This works…. but could be better…

Since listening to scroll events may cause performance delays.
And continuous polling always runs in the background… which might be a load to the CPU even when the target element is not moving.

So, this is an approach / experiment to see if we can do something with the Intersection Observer to observe position changes of html elements.

The Approach:

Intersection Observers are very good at reporting if the target element actually intersects with a root element. They can report fractional changes of intersection between the target element and root element, which happens when the target element moves.

We also have the provision to change the dimensions of the capturing window (the rootbounds) by modifying the margins of the rootBounds.

Hmm…

The Idea:

So the idea is to use the capturing window to tightly wrap around the target. This means when the target element moves , it hits and intersects with the capturing window and thus the Intersection Observer reports the minute intersections using a high threshold array (from 0 to 1 in divisions of 1/1000ths). That means the Intersection Observer reports every 1/1000ths of change in intersection area between the target and root (the capturing window)

If it moves out of the capturing window completely (this happens when the intersection ratio is 0), then we again change the margins of the root (the capturing window) to be around the new target position.

Implementation problem I faced and how it is solved now:

The approach worked fine, till I encountered scrolling situations, where the target was within the visual viewport dimensions (within the screen) but hidden visually as it was hidden in the scrolling context.

In this scenario, the intersection ratio was always 0 since the intersection only reported when the target was within the visual area.

So to solve this , the approach I took was this.

When the intersection ratio is reported to be 0…
The Intersection observer is disconnected and then reconnected with new settings:
 
The capturing window dimensions is made to be the whole screen (that is with root-margins as 0).

And the callback for this scenario is made in another method so as to differentiate between the moments when the rootbounds is the visual viewport and when it is just around the target.

So when the Intersection Observer now reports any intersection-ratio less than 1, we don't do anything. For every report, we say there is a position-change. 

When the ratio turns 1, this means the target is fully within the visual area. During this moment, we again disconnect the Intersection Observer and reconnect with a finer window around the target again with the previous callback method.

So the capturing window (rootBounds) ultimately cycles between the finer window and the visual viewport.

How to implement it ? Is this already implemented ?

Yes. I have implemented the same as a PositionObserver class in my Github repo (https://github.com/AJK-Essential/Position-Observer) . The files are located within the dist folder. These files can be downloaded.

Then
the PositionObserver class can be imported like this:

import { PositionObserver } from "./position-observer.js";

Then create an instance of this PositionObserver like this:

const positionObs = new PositionObserver(posObsCallback);

where posObsCallback is any function that accepts an object argument of type:

 {
  x: number;
  y: number;
  target: HTMLElement | Element;
  outOfViewport: boolean;
  rootBounds: DOMRect | null;
};

Example implementation of the position observer callback would be:

function posObsCallback(data) {
    overlay.style.top = data.y + target.getBoundingClientRect().height
 + "px";
    overlay.style.left = data.x + "px";
    console.log(data.x, data.y, data.outOfViewport,
 data.rootBounds, data.target)
}

This would be the function that would be called as a callback when the positionObserver detects position-change. The properties of the object received in the callback are :

• x : represents the x coordinate of the target
• y : represents the y coordinate of the target
• target: represents the target itself
• outOfViewport: represents if the target has gone out of the visual area of the viewport
• rootBounds: represents the boundary of the root element or the capturing window. Useful for debugging purposes.

Till now the positionObserver has been setup. Now to detect position-change of an element, we need to observe it like:

positionObs.observe(target);

where target represents the actual element we want to observe.
To stop observing position-change, we can use it like:

positionObs.disconnect()

You may also visit https://github.com/AJK-Essential/Position-Observer/blob/main/docs/target-scroll.html and see the script section to see an example implementation

Limitations of this observer:

1. It can only detect position-change when the target moves within the visual area.
2. When there is size change of viewport or target, it may fail. So in those scenarios, better to disconnect and then observe the target again.

So is this the perfect solution ?

I don't know. It worked as per my testing. There may be scenarios where it may not work…
What I would recommend is to use this in combination with listening to scroll (and use it just as a replacement for continuous polling) since I observe sometimes it misses tracking the target when scrolled in the demo.

Feel free to use and test the code in this Github repo
(https://github.com/AJK-Essential/Position-Observer), and even modify it privately to suit your project/business needs or if you have found a bug and have the solution as well for the same.

Hope this was of some help !