Review the PerformanceContainerTiming attributes names
Nobody has claimed this yet.
- Dominant language
- Bikeshed
- Stars
- 72
- Forks
- 10
- Avg merge
- 9d 15h
- Merged PRs (30d)
- 3
Description
Currently, the PerformanceContainerTiming IDL has these attributes and functions:
From PerformanceEntry: entryType, name, startTime, duration, navigationId, toJSON(). Those are coming from other specifications, so not the scope of the discussion here.
Then, for PerformanceContainerTiming itself:
intersectionRect: copied fromPerformanceElementTiming, the intersection of the paint rectangles in the viewport.size: the area in pixels of the view port that have been painted.identifier: the ID set as the parameter of thecontainertimingattribute. Again consistent withPerformanceElementTiming.lastPaintedElement: one of the element that has been painted last. We use theelementsuffix for consistency with theelementattribute in LCP, ICP.firstRenderTime: again, for consistency with what we get inPerformanceElementTiming, the fieldrenderTime, but this is the first render event.
And new attributes that are expected to land in the spec:
rootElement: the container timing root. With the suffixElementto give consistency withlastPaintedElement.
Also, we are moving to support the Paint Timing Mixin. This brings us two new attributes: paintTime and presentationTime.
Some problems:
identifierrefers to thecontainertimingattribute value. But we also have the node ID. Should it berootIdentifier?- Do we need the
Elementsuffix? This was for consistency with the fact that we have theelementattribute in other paint events, and to state the difference between the observed root and others. - The "root" concept may not be obvious. Specially if we want consistency with
elementtimingwhere we should also offer a reference to the observed element. If we want to add toPerformanceObserveran specific API for observing only a container timing root or element timing node, then... maybeobservedElement,observedorobservedRoot? firstRenderTime, but we do not offer arenderTimeattribute, as it is alwaysstartTime. We should likely add arenderTimeexplicitely for consistency. Specially if we could eventually move to unify the API.- Should we expose, if mixin is enabled,
firstPaintTimeandfirstPresentationTime? sizeis not very specific. Should we rename it to something likepaintedArea?lastPaintedElement: should it belastRenderedElement?
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 PerformanceContainerTiming IDL and compare its listed attributes with the referenced PerformanceEntry, PerformanceElementTiming, LCP, ICP, and Paint Timing Mixin APIs. Resolve the naming questions around identifier, rootElement, render and paint times, size, and lastPaintedElement, with a consistent final attribute set as the outcome.
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
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 20/100