My one question: does carousel need a viewportCallback? Or is it only for its children?

Yeah, if we did something like this, we should look into how to do this higher up for other elements as well. But I do think the elements have to opt-in.

@dvoytenko It's to start/pause autoplay. The actual signal here is visibility, so I'm unsure what a better model would be.

@dvoytenko It's to start/pause autoplay. The actual signal here is visibility, so I'm unsure what a better model would be.

Got it. We need do something like this. But it looks like for now it's only needed in inabox? Can we use some API separation for inabox to limit this for now?

@dvoytenko RE: siloing to inabox, should we try to get rid of viewportCallback in general in favor of IntersectionObserver everywhere?

This would also remove the need for a scroll-bound event handler on video, and help with embedding video components and amp-timeago on Bento.

@dvoytenko RE: siloing to inabox, should we try to get rid of viewportCallback in general in favor of IntersectionObserver everywhere?

This would also remove the need for a scroll-bound event handler on video, and help with embedding video components and amp-timeago on Bento.

If we talk about the future: absolutely, I'd like to get rid of the viewportCallback and use InOb instead. However, a few things will have to change for this and that's why I recommend solving this for inabox first. Things that need to change before we can do this in the main AMP codebase are:

1. We will need to switch from a generic viewportCallback to a more feature-specific InOb and it always has to be opt-in. In other words - viewportCallback should no longer be called on every single element. Instead loader system could use its own InOb and other features could use their own.
2. We need to solve for InOb polyfill. Or, alternatively, we could define a behavior when it's absent per feature. For some features it could be the feature is disabled (e.g. loaders are disabled entirely on IE) vs some other features we assume an element is always in viewport (yeah, bad for performance, but...).

We will need to switch from a generic viewportCallback to a more feature-specific InOb and it always has to be opt-in. In other words - viewportCallback should no longer be called on every single element. Instead loader system could use its own InOb and other features could use their own.

It sounds like we can make the opt-in API here similar to the InOb-specific API you mention, just removing knowledge of viewportCallbacks but not siloing it to inabox.

We need to solve for InOb polyfill. Or, alternatively, we could define a behavior when it's absent per feature. For some features it could be the feature is disabled (e.g. loaders are disabled entirely on IE) vs some other features we assume an element is always in viewport (yeah, bad for performance, but...).

Fair, I believe this PR still leaves the opportunity for that to be solved in the future. FWIW, IE is left out from this workaround.

Let me know if I'm missing something about making this specific to inabox at the moment.

Discussed offline with @dvoytenko and @jridgewell. We're special-casing some component types on InaboxResources to keep viewportCallback API the same.

@lannka @dvoytenko @jridgewell

PTAL, ready for review.