Use visual viewport instead of layout viewport for root intersection rectangle?

[ChumpChief]

The definition of the root intersection rectangle specifies that for intersection roots which are document viewports, it is specifically the layout viewport.

I think this should instead be the visual viewport to better align with the stated goal in the spec of "calculating element visibility".

There is a corresponding note that this choice was intentional, implying there was intent of keeping the root intersection rectangle closely related to layout dimensions (specifying that pinch zoom changes neither). If that is still true and this change is rejected, then the relationship between IntersectionObserver and layout dimensions should be better explained. The goals outlined in the spec currently sound more relevant to "what the user sees" than "how the page is laid out".

I would also be concerned that leaving this as the layout viewport would leave the "exotic plugin-based solutions" for ad impression tracking as more-effective than IntersectionObserver and discourage uptake.

Alternatively, if there are scenarios which require intersection against the layout viewport, then an option to specify layout vs. visual viewport as the root intersection rectangle could be interesting.

[szager-chromium]

You are correct that the intention is visual viewport; marking this "needs spec".

[ChumpChief]

Sounds good, thanks. As a followup, it should probably be made explicit what the coordinate space is for rootMargin then.

I think it should be measured in the visual viewport's coordinate space, e.g. such that 100vh represents content that is one page away, or approximately one "page down" press away. As opposed to the layout viewport's coordinate space, where 100vh in that coordinate space may be multiple "page down" presses away depending on the user's pinch zoom level.

[szager-chromium]

Actually, I'm sorry, my previous reply was incorrect. After clarifying this with some of the people involved:

At least for the first release, IntersectionObserver will track intersections with the layout viewport, not the visual viewport. The primary reason for this is that by tracking the layout viewport, we are not revealing any new information to cross-origin iframes than they currently have. IntersectionObserver will provide the same information that is currently available, but it will do it more accurately and more efficiently (in terms of performance and battery consumption) by eliminating the need for pollers or scroll event handlers.

Tracking intersections with the visual viewport, while unquestionably useful, is also likely to be more controversial, so we're punting on that for now, pending more discussion with browser vendors.

[ojanvafai]

@ChumpChief that sound OK to you for now?

[ChumpChief]

I would also be concerned that leaving this as the layout viewport would leave the "exotic plugin-based solutions" for ad impression tracking as more-effective than IntersectionObserver and discourage uptake.

@ojanvafai The impression I had from our previous in-person conversations is that these plugin-based solutions were already able to detect whether the ad (even cross-origin) was truly within the visual viewport based on paint timing. If that's correct, and IntersectionObserver is less-capable in that regard, is that not an argument against moving to IntersectionObserver from current implementations?

I think (please let me know if I'm wrong) @szager-chromium 's comment was in the spirit of aligning with this behavior Chrome was experimenting with. However, that change was reverted since then, so the desire to hide visual viewport intersection seems less-applicable. Does the Chrome team still feel it's interesting to hide the visual viewport from IntersectionObserver despite it being revealed by other functionality?

Tracking intersections with the visual viewport, while unquestionably useful, is also likely to be more controversial, so we're punting on that for now, pending more discussion with browser vendors.

As far as I can tell, the intersection with the visual viewport is the only one that's actually interesting for the targeted scenarios for this feature - the layout viewport is never the useful one here. Were there any other objections to using visual viewport that I'm not aware of?

[mpb]

As far as I know, the visual viewport vs layout viewport distinction is mostly relevant for non-mobile-optimized pages on mobile devices where "pinch zoom" is used. In this situation, none of the "exotic plugin-based solutions" should be viable, since Flash would not be available in this scenario. So that would not be a reason for people to halt adoption of intersection observer for viewability use-cases.
Unless anyone can point out a situation where the visual/layout distinction is relevant and there are plugin solutions available.

[jacobrossi]

@mpb many mobile optimized pages still allow pinch zoom for various use cases and some browsers allow overriding a page that disables pinch-zoom for accessibility purposes.

[szager-chromium]

@jacobrossi But plugin-based solutions are not available on mobile, so IntersectionObserver is at the very least no less useful than anything else available, right?

[szager-chromium]

@ChumpChief the situation with pinch zoom is not so clear. This comment explains that reverting the behavior of window coordinates is temporary, until something more permanent is figured out. I think at the very least IntersectionObserver should not leapfrog that effort.

[ChumpChief]

@ChumpChief the situation with pinch zoom is not so clear. This comment explains that reverting the behavior of window coordinates is temporary, until something more permanent is figured out. I think at the very least IntersectionObserver should not leapfrog that effort.

The debate over those APIs is one of web compat. The same arguments don't apply here, as it is a new API. If those properties still reflected the layout viewport I could understand (though not agree with) an argument for consistency, but at least with the change reverted that doesn't apply.

Regardless of where that discussion lands there remains the argument I initially put forth -- visual viewport accurately satisfies the explicitly stated scenarios listed in the spec ("calculating element visibility"); layout viewport does not. I think we can agree on that?

[szager-chromium]

The main thrust of the pinch zoom issue is that pinch zoom should be essentially invisible; it should not trigger layout or events. Using the visual viewport here would run contrary to that.

One of the main drivers of this API is to reduce jank caused by unnecessary scroll event handlers. I would be very cautious about introducing a new jank opportunity in the form of intersection observer callbacks responding to changes in pinch zoom.

I don't think this is a settled issue, but I think it's prudent to use layout viewport in the first iteration of this spec, and revisit this issue for v2 (which we are already know we have to do). By that time, hopefully the pinch zoom issue will be in a more settled state.