DEV Community

Cover image for Observing position-change of HTML elements using Intersection Observer
AJK-Essential
AJK-Essential

Posted on • Edited on

Observing position-change of HTML elements using Intersection Observer

#webdev #javascript #typescript #intersectionobserver
Credits:

I want to clarify that while the code in this post (and in Part 2) was developed entirely by me, the idea behind this implementation originated from this StackOverflow discussion:

“How to observe DOM element position changes” — https://stackoverflow.com/questions/59792071/how-to-observe-dom-element-position-changes

The original post presented the concept, but not an implementation. I explored the idea, built the implementation myself, and wrote this article to explain how it works and how to use it. Many thanks to the original author for the inspiration.

💡 Related:

There is a Part 2 of this article where I explore another variation of the approach.

Check it out here: Position Observer – Part 2

TL;DR:

Use an IntersectionObserver to observe position changes of elements without listening to scroll events or performing 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 rely on listening to scroll events on parent elements or use continuous polling (e.g., requestAnimationFrame).

These approaches work, but come with issues:

  • Listening to scroll events can introduce performance delays
  • Continuous polling always runs in the background, creating unnecessary CPU load even when the target isn’t moving

So the goal of this experiment was to explore whether we can leverage IntersectionObserver to detect position changes instead.

The Approach:

IntersectionObservers 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.

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 IntersectionObserver reports the minute intersections using a high threshold array (from 0 to 1 in divisions of 1/1000ths). That means the IntersectionObserver 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 IntersectionObserver is disconnected and then reconnected with new settings:
 
The capturing window dimensions are expanded to cover the entire 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 IntersectionObserver 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 IntersectionObserver 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";
Enter fullscreen mode Exit fullscreen mode

Then create an instance of this PositionObserver like this:

const positionObs = new PositionObserver(posObsCallback);
Enter fullscreen mode Exit fullscreen mode

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

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

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)
}
Enter fullscreen mode Exit fullscreen mode

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.

At this point, the PositionObserver has been set up. Now to detect position-change of an element, we need to observe it like:

positionObs.observe(target);
Enter fullscreen mode Exit fullscreen mode

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

positionObs.disconnect()
Enter fullscreen mode Exit fullscreen mode

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

  1. Can only detect position changes when the target moves within the visual area.
  2. May fail when viewport or target dimensions change — in such cases disconnect and observe again.

So is this the perfect solution?

I don't know 😊 It worked well in my testing, but there may be edge cases where it might not.

What I would recommend is to use this in combination with scroll listeners (instead of continuous polling), since sometimes it may miss tracking during rapid scrolling in certain scenarios.

Feel free to explore, test, and modify the code in this GitHub repo:

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

If you find improvements or bugs, I’d love to hear about them!

Thanks for reading — hope this was helpful ✨

Top comments (2)

Collapse
 
itihon profile image
itihon •

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.

Collapse
 
ajk-essential profile image
AJK-Essential •

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 😎👍