since you're using const/let, you don't even need the IIFE, just {} the outside for a dummy block and be done with it.

I'm not certain I follow why you check for resizeObserver if this is code that would/should only be included/executed once... I honestly think that resizeObserver is a solution in search of a problem, as I've NEVER ONCE EVER seen the alleged "race conditions" people talk about with the normal event, and I don't see how having individual events fire for every joe blasted element is an improvement. It's complex, convoluted, and in no way better that I can tell.

Though I could be mistaken on that, it's just every example I've seen of people using it has nothing to do with what/how resizing would be needed and in many cases is stuff I'd not even be wasting more JS on than the onchange event and setting a CSS property. I rejected it very early on thanks to the garbage way MDN's example does... what it does. 90%+ of the scripting they have in their example belongs in the trash.

And I wouldn't call the endless nesting and multiple observer hooks an improvement. It adds a LOT of processing overhead for what would/could/should be a single event. Particularly given how much stuff looks to be passed around on the stack or whatever JS uses as an equivalent. There's a reason I dislike "forEach" given how brutally inefficient it can be. Why add a callback for each and every iteration tripling the overhead?

I was thinking that a possible improvement could be to walk the child elements to add their height all together, so you could have more than one block-level child. Problem with that is how textNodes and non-block or non-flow elements would behave in regards to that.