Hey so I tried this out in my chat app and as new messages come in, and the message-list target node expands, I thought ResizeObserver should fire(?) It only triggers once on the initial page render in this case... Am I off on how this should work?

    const rs = new ResizeObserver(() => {
      console.log(arguments);
    });
    rs.observe(document.querySelector('.message-list'));

Rather than using granular steps for intersection ratio; why not use two elements?

Given one element A resting on the inside of the right-bottom corner of the target element and one element B resting on the outside of the right bottom corner, i.e. ,

I.e.

------------------------------
| target                     |
|                            |
|                        ----|
|                        | A |
----------------------------------
                             | B |
                             -----

When the target becomes smaller, A will change its intersection from 1 to less than 1.
When the target becomes bigger, B will change its intersection from 0 to more than 0.

When either element changes its intersection, update the top and left offset of A and B to reseat them in the new corner position and then create a record for the ResizeObserver to call back with.

During creation of the record and reseating the detector elements, you would query the DOM for the size of the element.

One of the first arguments against such a solution would be that having to query the DOM is less efficient than directly re-using the intersection area reported by an IntersectionObserver.

However; note that this intersection area cannot be used directly.

ResizeObserver is supposed to report the content box area, whereas the intersection area reported by an IntersectionObserver is based on comparing border boxes. Thus even if you wanted to use the intersection area directly, you'd still need to query the DOM for the target element's border and padding widths and subtract those to arrive at the content area.

At that point you'd be stuck using multiple window.getComputedStyle calls to figure out padding and border to subtract. That is probably going to be atleast as expensive, if not more so, than querying an element's clientWidth and clientHeight.