Clarify the `lastPaintedElement` semantics, and consider using "largest element (in this paint update)"

[mmocny]

I see that there are notes in the README that this attribute may need to evolve into a list:

"this may need to be a set of elements painted"

(But I somehow doubt that this API will evolve to actually report the FULL list of all elements.)

The current specification implies that this value would be the literal last element that updates area, even by 1px, based on implementation defined paint order. (see https://wicg.github.io/container-timing/#maybe-update-last-new-painted-area and https://wicg.github.io/container-timing/#ref-for-maybe-update-the-last-new-painted-area).

We recently worked on changes to the LCP spec to try to remove paint implementation order differences w.r.t. LCP candidate reporting. We resolved this by taking two passes:

• First, taking ALL element paints in one rendering update, and find the largest overall for that paint
• Then, compare that element against the previous largest candidate from all previous paints to see if we have a new largest.

This way, the relative element paint order doesn't matter for candidate selection.

---

I wonder if a model like this could be borrowed for Container Timing?

I think you already observe the same stream of paints at the same moment and order as LCP. After filtering down to elements which are part of a container tree, you could iterate the elements from largest to smallest element, and find the largest element that actually does update the size of the region.

Alternatively, you could keep a copy of the previously recorded region while you are updating the new region, and consider any element that would update the old region by even 1px to be a viable candidate -- not just those elements which update the current region.

(FWIW, Container Timing right now just has a "When an element is painted" hook which is per-element, but this isn't the right integration with paint timing nor element timing, I think)

See:

• https://www.w3.org/TR/largest-contentful-paint/#sec-report-largest-contentful-paint
• https://w3c.github.io/element-timing/#sec-report-element-timing
• https://www.w3.org/TR/paint-timing/#mark-paint-timing (Step 10.3 and 10.4)

[mmocny]

A second oddity of the current behaviour, I think, is that container timing paints are only reported when overall size actually increases.

At face value, this makes sense, but for stacked content updates it means that the stream of paints is dependant on the size overlap between them.

Take this example:

• A stock ticker starts at 99.9$, fires an CT entry.
• Updates to 100.0$, fires an CT entry.
• User reloads the page
• A stock ticker starts at 100.0$, fires an CT entry.
• Updates to 99.9$, does NOT fire a CT entry.

Thus, the page loads slower only when the stock goes up.

---

There is NOTE about this in the spec:

Note: This algorithm reports any change to the painted region, regardless of size. Even a 1 pixel change in the painted area will result in a new PerformanceContainerTiming entry being queued. Developers who wish to filter out small changes may do so by comparing the size values between entries.

This makes sense. But what if I wanted to do reverse? What if I wanted to observe the second update paubnt, even when it has a 1px smaller size than the previous region?

---

An alternative mechanism for Container Timing would merely report all paints, whenever those paints have any new contentful element paints within the container. The container size overall may not change with every update, but each update would have its own lastPaintedElement which could be the largest for that paint.

This would solve two problems:

• Give developers more ability and options for observing a stream of contentful paints within their containers (potentially all the way to to "Fully visually complete").
• Enable a mechanism for reporting new elements that are very large but within previous parts of the container region.

[jdapena]

I like the idea of LCP. And it may not be hard to implement. Right now we store the lastPaintedElement, that is easy to maintain as we just update the value when a new paint is increasing the damaged area.

Possible alternates

Alternative 1

Cheap, but less consistent.

We set lastLargestPaintArea to 0 when we emit a container timing entry.

Then, as we get new paints:

• First we see if the new paint increases the region.
• If the region is increased, we compare the painted area with lastLargestPaintArea. If it is bigger than previous value, then we store lastPaintedElement (or rename as lastLargestPaintedElement).

Then when next container timing entry is generated we use the lastLargestPaintElement

Problem: as we increase the area, a largest paint that is not increasing the area (but could have been detected as increasing if processed before) would not be showing. As we emit the entry for each frame, it should not be a big deal.

Alternative 2

We could maintain a lastEmittedRegion, that would be the region emitted in the last container timing entry.

Then, for all paints, we see if they increase the painted region compared to the lastEmittedRegion, and in that case we compare with the lastLargestPaintArea.

Relation to other changes

Continuous tracking

Both ideas would work properly for a new continuous container timing tracking event (container-paints?) that would just emit always even if it does not increase the region. They would just, for each paint affecting a container timing, reflect the total painted area, the intersection rect of it, and the largest painted element.

Exposing the region

If we want to expose accurate information about the parts of the screen that were actually damaged, we could expose the regions. This would apply both for continous tracking and current container timing. We would have the data ready and we would just need to provide a way to extract that from the container timing entry. The overhead would happen only on accessing the attribute.

[mmocny]

Related: consider adding a sizeDelta attribute to the container timing, so you could report paints for a 0 delta and it would still be clear.

---

This also reminds me of CLS, which accumulates score of shifts over time. Most libraries that implement this accumulation will report a running total CLS score, as well as attribution about the most recent shifts, and a delta value from last update. But not all reports increase the score.