Is there any mechanism for observing that the whole container has "finished" painting?

[mmocny]

I understand that with Container Timing there are various issue that may make it impossible to know that a Container has fully finished painting:

• Some content may be below-the-fold, and user may scroll
• Some content may be offscreen, transparent, or obscured in ways that skip paint, but may move.

Etc.

But what about simple cases like: a container timing attribute applied to a single element leaf node (aka the element timing use case)?

Or for simple containers, where all potentially-contentful leaf nodes are known, and have all already reported contentful paints?

[jasonwilliams]

So there is currently no mechanism for this, its an interesting use case.

That said, I don't know how definitive it is, for instance, even with the simple container example, we don't know if code could ever be injected in at a later stage and we now have more paints than we knew of before. And a leaf node like a canvas, potentially signaling there's new areas being painted.

It would only be text or image leaf nodes where we can guarantee this for certain, and even then its dubious (such as a late font being downloaded and causing an increase of font size).

Do you think there's a valid use case for having a "finished" state?

[mmocny]

Thanks!

(FWIW, late font swaps don't typically re-emit new paints, since we only emit a single paint per element right now, for element timing or LCP, afaik-- though we could change that, and maybe container timing does?)

Do you think there's a valid use case for having a "finished" state?

In general, a lot of developers ask for "when is it visually complete?" style signals.

But I think the specific reason I asked this question was to know if container-timing could be a drop-in extension of element-timing for the case of a single leaf node (or for cases where the content feels like a single leaf node even if its technically a simple container-- like e.g. we do by default for text aggregation nodes).

[tunetheweb]

One thing to be aware of is the rehydration case, when an element (or more precisely a new identical copy of an element) is remounted and so can appear to re-emit. This can happen with element timing too. We've had complaints about LCP for this and this could apply to element timing and container timing.

[jdapena]

One thing to be aware of is the rehydration case, when an element (or more precisely a new identical copy of an element) is remounted and so can appear to re-emit. This can happen with element timing too. We've had complaints about LCP for this and this could apply to element timing and container timing.

I don't think we can do much to improve this? Recreating the tree may imply new container timing roots, and also new elements. I would expect duplications because of this to be done by web users.

[jdapena]

About a mechanism to know if painting has finished...

When we get an element painted, we would need to record that. This goes to something we discussed before about elements recording themselves when they have been painted. So, prepaint could know which nodes are pending and associate that to each container timing root. It could even be just a count.

Then, on paint, each element painted would remove itself from the pending count or list. If it becomes zero, a specific container timing entry could be generated (not the container timing entry we have now).

Something like... "ContainerTimingPaintComplete" entry that would report that all elements have been painted.

Some questions or ideas:

• Should this complete event be a PerformanceEntry? Or a new observable event that only container timing roots would generate?
• Should we have a method in "any" HTMLElement that would be HasPaintedCompletely() or similar?

[mmocny]

Should this complete event be a PerformanceEntry?

I think it would only ever change with new painted content, so could just be an attribute on the existing CT entry.

However, it could be possible that we paint content that doesn't increase size of the container, though, so this would mean potentially a new CT entry just to mark the state change without any reported elements.

Should we have a method in "any" HTMLElement that would be HasPaintedCompletely() or similar?

I asked a similar question RE element timing and if we could add .painted() style method to elements alongside .decoded() but I was given a reason why this should not be possible, but I don't fully recall exactly why :( (I think it was it was just that the current observer pattern doesn't hold strong references to elements, while a promise api would, and could be a foot-gun if devs start to use it for every rendered element-- though possibly doing it only for CT roots helps...)

[mmocny]

Also-- I wonder if instead of saying "is-visually-complete: true" we should say "has-known-pending-content: false"

The latter is an easier contract because we don't know if more content gets added that resets that state...