This is an older post. You can read through this current post to get the gist of the tech. And then you can read the post here https://dev.to/ajk-essential/position-observer-part-2-2ojb for an updated better alternative where the concept is not explained much, but a better algorithm is presented with a newer demo.
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:
- It can only detect position-change when the target moves within the visual area.
- 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 !
There is a part 2 to this: Check it here where I address one issue and another better approach is used:
https://dev.to/ajk-essential/position-observer-part-2-2ojb
Top comments (2)
I wanted to thank you for your article. This is an interesting approach. I started to work with your solution a couple of weeks ago, it helped me to figure out how to make "capturing window" dimensions consistent on desktop and mobile screens. The problem of viewport size change can be solved by setting rootMargin in percents relation of target's coordinates to viewport's dimensions. But this way, "capturing window" starts running away from target on viewport resize. Although it triggers position change detection, it creates other possibilities to fail. Also it seems impossible to reliably detect target's resize. So I tried another approach, to use four observers: one for each target's side. In case you want check what I finally ended up with, it's here: Position observer demo.
Thanks a lot for trying my code and commenting 😊.
The demo looks very good 👍👍👍
I have also made another approach here (very similar but little addition to make it capture even more efficiently... )
dev.to/ajk-essential/position-obse...
but yes, the problem of not doing anything on resize is there. It was an intentional left-out so that consumers of the library can disconnect and observe again on size-change of viewport or target, (so that the library is not over-complicated)
Thanks again for remixing my approach and code 😊. I appreciate it so much 😎👍