Consider using the layout viewport instead of the visual viewport

[jdapena]

In Container Timing, we are using the same definition of intersectionRect that comes from Element Timing. For each paint, we calculate the intersection of that paint with the browser viewport.

We use that rectangle to then record the damaged area for a container timing. Anything painted offscreen is not reported. This is a limitation of Container Timing as is that is not going to report paints offscreen, that may be later visible to the user when the scroll down.

Now, checking at https://drafts.csswg.org/cssom-view/#visual-viewport there is the concept of visual viewport and layout viewport.

The proposal is:

• Use the layout viewport for the internal damage recording and the size attribute.
• Expose a new field layoutIntersectionRect that exposes the bounding box of the damaged areas related to the layout viewport.
• Have a new attribute viewportIntersectionRect that is calculated when PerformanceContainerTiming is created. Make intersectionRect expose that same value, for compatibility with the current proposal. Or just directly drop intersectionRect completely and avoid exposing the viewport intersection.
• (Optional) Should we do the same change in ElementTiming?

With this proposal we would have some advantages:

• We could report paints that are not in the visible area for the user.
• We would be a bit more stable in the case of viewport scrolls or zoom, as those would not affect coordinates.

Potential problems:

• Is the layout viewport really well defined? Is that information useful for the developer to know where a paint has really happened? Will it be possible to add overlays from web using that?
• We already have a Chromium implementation using the visual viewport. So if we change and there are assumptions on where the visual viewport is painted, those would be broken.
• The polyfill is based on the element timing intersectionRect.