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.

[jasonwilliams]

I don't think the viewport coordinate space is what we want, and i agree that we should use something like the document space or the space of the container root.

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.

I don't think the first one is an advantage.
Reporting offscreen paints adds complexity for a use case that doesn't align with the core goal.
Container Timing is about measuring when content the user can see has finished painting, similar to LCP. If something
paints offscreen, the user hasn't experienced it yet. Reporting it would muddy the signal developers actually care
about ("when did my component appear ready to the user?").

It sounds like there's some options:

1. Viewport-relative - what both implementations currently do, but scrolling would incorrectly affect it and moving around increases size
2. Document-relative - fixes the scrolling issue, but container movement still causes the region to grow incorrectly.
3. Container-root-relative - what I would expect as a developer; moving the container doesn't change size, so
     percentage-complete calculations stay correct.

Is container-root-relative a better option here (for the rects contents of the container), although this would present some edge cases, such as what do you do if the container expands (would this void the current coordinates of the rects inside and they need to be recalculated)?

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?

I don't think we should increase the API surface area for a small use case (OT users aren't even using this field so far). I think we could switch to making intersectionRect based on the layoutIntersectionRect instead of relative to the viewport, I'd be ok with keeping a field for backwards compatibilty for OT users but not permanently.

[jdapena]

https://chromestatus.com/metrics/feature/timeline/popularity/5734 points that intersectionRect is not really used so far in the origin trial. We could even skip showing it. Or keep it as is.

I like the idea of making the rect container timing root relative, but what would happen with offscreen paints?