@ylafon and I took a look at this during our London F2F this week and, broadly speaking, this seems reasonable to us. We're wondering if you've thought about this edge case, though:

Say you have a large website that many developers have hacked on. Before the introduction of this feature, someone does something roughly equivalent with IntersectionObserver and MutationObserver as you've alluded to. Later, after the introduction of this feature, someone does something else on the same site, with the same subtree, with the new element. Is there any risk that this new event handler could cause a cycle with the old code? Is there a way for the spec or the implementation to mitigate this?

So I understand correctly, do you mean if there's both an IntersectionObserver type of code and this new event handling? I can't immediately think of a situations where this can cause a problem where both handlers are triggered in a loop. The only way that would be possible is if one of the handlers changes layout of the page such that the affected c-v element keeps being toggled between skipped and not skipped states. But that seems like a behavior that could already be caused with only one of IntersectionObserver or this new event. IOW (and IMHO), nothing fundamentally changes now that there are two different ways to observe these state changes.

I hope that answers your question

Hi @vmpstr,

Thanks again for bringing this to our attention. We're happy with your design and will close this review. We are hoping that you can note (non-normative text would be fine) the possibility of cycles with related features in the spec, so that authors can be warned, but we're not blocking the review on that.