@smfr I cannot add you as an explicit reviewer, but fyi. (Let me know if you would like to be a reviewer for these in the future)

Are we good to land this @mmocny ? Was trying to support the Firefox behaviour in web-vitals but gave up so landing this so they can change would be good!

Ah see we tagged @smfr (for webkit) above but not @Bas-moz (for Mozilla).

Any comments @Bas-moz ?

This change looks good to me.

These changes remove the notion of the "content set" that ensures that a given element is reported only once. This is described by the Note in 4.2, but Notes are not normative, so what normative text describes this?

@smfr Scott has similar question in his review but we realized that the Paint Timing that tracks painted images and which calls into this algorithm already has a "content set" concept.

Specifically, images are only reported exactly once each, when finished loading and text has a set of elements with rendered text.

I do think there are a few more updates that need to be made to that spec (which I think you pointed out last year?) such as what happens if the same loaded Image is attached to multiple different Nodes, or when is the opacity check enforced. But AFAIK those issues equally affect the current wording so this change is a step forward.

WDYT?

Having to refer to another spec for that is not great. Can we at least have a Note that refers to Paint Timing?

Having to refer to another spec for that is not great. Can we at least have a Note that refers to Paint Timing?

The note that I added links to paint-timing/#mark-paint-timing, but I can update however you recommend.

(Honest question, I don't know how to type that in a way that cannot be interpreted sarcastically :P I might not know of a better way to cross reference another spec that you are expecting!)

FWIW, LCP spec already depends on paint timing in a deep way already for its image/text paint notifications, anyway. If it was some weird spaghetti back and forth I would agree with you that it is not great, but I think we're getting to the point of being a fairly clean separation:

• Paint Timing defines which specific element paints are considered "contentful" (i.e. the first paint after content is loaded & visible to user)
• Other specs observe this stream of element paints (LCP, but also element and container timing) and filter/map/reduce them.

We did discuss at TPAC if it's more convenient to just merge everything into a single spec (simplify things, and its weird that paint timing defines but doesn't use element-paints itself), but decided it was best to leave most of the complicated algorithms in a single spec (Paint Timing) and the other specs sitting above were narrowly scoped to defining the PerformanceEntry interfaces and the specific value they bring relative to others (i.e. LCP adds "largest area" semantics and element attribution).

We thought this had some minor advantage in terms of documentation, and also better for historical/documentation reasons not to drop having a dedicated LCP spec that devs occasionally expect to find.

The note that I added links to paint-timing/#mark-paint-timing, but I can update however you recommend.

(Honest question, I don't know how to type that in a way that cannot be interpreted sarcastically :P I might not know of a better way to cross reference another spec that you are expecting!)

Sounds reasonable and not sarcastic to me :).

Thanks for all the feedback, I'll land this now because Scott is working on a (tentative) WPT update to check this (Bas-- Mozilla will fail initially until fixed).

We can iterate on remaining wording if needed. Cheers!