Observing position-change of HTML elements using Intersection Observer - Part 2

Hi, This is a follow-up work I did on the post I made here : https://dev.to/ajk-essential/observing-position-change-of-html-elements-using-intersection-observer-12de TLDR: Observe the position-change of HTML DOM elements using both intersection-observer and a requestAnimationFrame . The intersection observer to start observing the motion and the requestAnimationFrame to observe when the target has stopped moving. New code link in github: https://github.com/AJK-Essential/Position-Observer/blob/main/src/version-2/position-observer.ts Demo: https://ajk-essential.github.io/Position-Observer/version-2/index.html (Check the consoles to see the logs) There I have mentioned the use of 2 intersection observer callbacks to catch motion of objects. But I also mentioned that sometimes it was not capturing the motion... And that was because of the abrupt changes that happen during the CPU cycles and this caused the intersectionObservers to not capture them properly. So what changed here ? Usage of request animation frames. Here, in this approach, the steps are as follows: Use an intersection observer to observe if the target is in viewport. If the target is in viewport, then modify the capturing window of the intersection observer to be just around the target. When the target has just crossed the finer window (intersectionRatio > 0 and < 1), then it means motion has started. Go to step 4. Else go to step 5. Stop observing. Start requestAnimationFrame that runs for certain time (user provided) using countdowns (not using setTimeouts or setIntervals) to check if the position has changed. If position has changed, restart the timer counter and repeat method. Else if position not changed, decrement counter of the timer. Else, this means it stopped. Then stop the requestAnimationFrame and go back to step 1 If it is completely within the finer window (intersectionRatio = 1) .. then it maybe indication that the object has stopped moving. But to be sure, we use another countdown requestAnimationFrame and follow same steps as 1,2 and 3 under step 4. If intersectionRatio was 0, then go to step 6 At this point, the target maybe a) out of the visible viewport. b) out of the finer window but within the visible viewport. In either case, we send it to wider viewport detection observer in step 1. Is it a bit better ? Yes it is better. Aren't we using a sort of continuous polling ? Yes. But only for a very short time (decided by you) and that too using requestAnimationFrame which is browser optimized. The difference here from full continuous polling is that we use polling only to detect whether the object has stopped moving or not. After that, we use the intersection observer to observe motion start. So using the strengths of both techs to its max here: The intersection observer to start observing the motion The requestAnimationFrame to observe when the target has stopped moving.

May 2, 2025 - 19:24

Observing position-change of HTML elements using Intersection Observer - Part 2

Hi, This is a follow-up work I did on the post I made here :

https://dev.to/ajk-essential/observing-position-change-of-html-elements-using-intersection-observer-12de

TLDR: Observe the position-change of HTML DOM elements using both intersection-observer and a requestAnimationFrame . The intersection observer to start observing the motion and the requestAnimationFrame to observe when the target has stopped moving.

New code link in github:

https://github.com/AJK-Essential/Position-Observer/blob/main/src/version-2/position-observer.ts

Demo:

https://ajk-essential.github.io/Position-Observer/version-2/index.html

(Check the consoles to see the logs)

There I have mentioned the use of 2 intersection observer callbacks to catch motion of objects.

But I also mentioned that sometimes it was not capturing the motion...

And that was because of the abrupt changes that happen during the CPU cycles and this caused the intersectionObservers to not capture them properly.

So what changed here ?

Usage of request animation frames.

Here, in this approach, the steps are as follows:

Use an intersection observer to observe if the target is in viewport.
If the target is in viewport, then modify the capturing window of the intersection observer to be just around the target.
When the target has just crossed the finer window (intersectionRatio > 0 and < 1), then it means motion has started. Go to step 4. Else go to step 5.
Stop observing. Start requestAnimationFrame that runs for certain time (user provided) using countdowns (not using setTimeouts or setIntervals) to check if the position has changed.
1. If position has changed, restart the timer counter and repeat method.
2. Else if position not changed, decrement counter of the timer.
3. Else, this means it stopped. Then stop the requestAnimationFrame and go back to step 1
If it is completely within the finer window (intersectionRatio = 1) .. then it maybe indication that the object has stopped moving. But to be sure, we use another countdown requestAnimationFrame and follow same steps as 1,2 and 3 under step 4. If intersectionRatio was 0, then go to step 6
At this point, the target maybe a) out of the visible viewport. b) out of the finer window but within the visible viewport. In either case, we send it to wider viewport detection observer in step 1.

Is it a bit better ?

Yes it is better.

Aren't we using a sort of continuous polling ?

Yes. But only for a very short time (decided by you) and that too using requestAnimationFrame which is browser optimized.

The difference here from full continuous polling is that we use polling only to detect whether the object has stopped moving or not. After that, we use the intersection observer to observe motion start.

So using the strengths of both techs to its max here:

The intersection observer to start observing the motion
The requestAnimationFrame to observe when the target has stopped moving.