WICG / WICG/container-timing

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

Open
#53 10 comments 0 reactions 0 assignees View on GitHub

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

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.