Clarify the `lastPaintedElement` semantics, and consider using "largest element (in this paint update)"
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 72
- Forks
- 10
- Avg merge
- 9d 15h
- Merged PRs (30d)
- 3
Description
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:
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the README note about lastPaintedElement and the Container Timing sections maybe-update-last-new-painted-area and maybe-update-the-last-new-painted-area. Compare their paint handling with the linked LCP and Element Timing reporting steps. Done means the project agrees on a clear candidate-selection model and records the resulting semantics in the specification.
Written by the indexing model from the issue text.
Assessment
- Domain
- documentation
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Active
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100