Pin paint timing and add missing keys

[captainbrosset]

The following BCD keys are missing from the PerformancePaintTiming API feature:

• api.PerformancePaintTiming.paintTime
• api.PerformancePaintTiming.presentationTime
• api.PerformancePaintTiming.toJSON

The toJSON one is easy to add, as it's already supported across the board.

The other ones seem to be newer additions, which only work in Firefox. I decided to add them to the existing feature instead of splitting them out onto their own feature, mostly because I don't know if they are seen as a separate enough thing.

I introduced a compute_from statement to pin the feature to the keys that make the most sense to me.
This API has been working for a long time already, and my feeling is developers use it to track the first-contentful-paint entry, which, according to my tests, works fine in all browsers.

BCD seems outdated, and @tunetheweb is fixing it. See https://bsky.app/profile/tunetheweb.com/post/3m22jwkg5hs2y

So, to sum up, with this PR, and with the BCD fix, the PerformancePaintTiming API feature will be Baseline Widely Available, matching the corresponding MDN Baseline banner.

[tunetheweb]

PR to fix BCD: mdn/browser-compat-data#28053

I'm not sure we should add paintTime and presentationTime just yet since they are so new (though they are in the spec now). I worry we will say that PaintTiming is not supported in Chrome (and Safari!) just because it hasn't landed these new additions yet. What's the relationship between adding APIs that are only partially supported and overal Baseline status?

Also First-Contentful-Paint (FCP) is Baseline Widely available, but First Paint (FP) is Chrome only and so isn't and the PerformancePaintTiming includes both (as well as these new additions). So does that change anything?

Or is it fine to say the API is Baseline Widely available, even if some feature of it aren't? Isn't Baseline supposed to remove that indecision for developers?

[captainbrosset]

This is what this piece of code is trying to do:

  compute_from:
    - api.PerformancePaintTiming
    - api.PerformancePaintTiming.first-contentful-paint

It's making the overall status of the entire feature match the status of these 2 BCD keys, ignoring the other keys.

The other keys are still part of this feature because they logically belong to it, and it doesn't seem like creating separate features for these other keys is useful. But, perhaps it is? Let me know if the ignored BCD keys can be seen as standalone features which developers might use for separate use cases.

Regarding FP vs. FCP, I read a couple of things:

• On MDN: "Note that the marking of the first paint is optional, not all user agents report it"
• In the spec: "The marking of first paint is optional. User-agents implementing paint timing should at the very least mark first contentful paint"

That's why I kept the api.PerformancePaintTiming.first-paint BCD key out of the compute_from statement (so its status doesn't impact the Baseline status calculation).

[tunetheweb]

Ah OK. In that case I'm cool. Thanks for confirming. I think FCP are what most people want out of this API. FP and the PaintTiming Mixin are optional extras as you say.

[Elchi3]

I think paintTime and presentationTime should be a separate feature.
There appear to be four keys: https://github.com/web-platform-dx/web-features/blob/main/features/draft/spec/paint-timing.yml

It's in Firefox, and Safari seems to be implementing it. It's all a bit confusing, I found this table to be useful w3c/largest-contentful-paint#145 (comment)

[tunetheweb]

I think it remains to be seen if Safari will implement presentationTime. They basically didn't for FCP (apparently cause it's not as much a concept in WebKit). In fact that's why we introduced these two values to make it clear what you're getting in each browser and to at least allow paintTime to be measured across browser engines.

So I don't think it's really that valuable as a separate feature. Especially since this concept will also be used for LCP and INP (so is that 3 new features, or all one new feature for all 3)? Ultimately what developers want is FCP, LCP, and INP and this is a subtle extra feature to explain why these are slightly different in different browsers.

Assuming that Safari does not implement presentationTime (and I work on Chrome not Safari so don't know this for sure), then we could make paintTime part of the compute_from in a couple of years since all three browsers should implement that and that will be the end state. As I say, I'm against adding that now, since it will regress the "Baseline" status of this, and since it's a new feature (as I say specifically to allow these metrics to be implemented across browsers fairly).

[captainbrosset]

Ok, so what's clear is that we should not add presentationTime and paintTime to this feature. Maybe we create another feature, but I guess this can be for another PR.

[Elchi3]

As I say, I'm against adding that now, since it will regress the "Baseline" status of this

I think we're on the same page. All I'm saying is that having this defined as its own feature will not regress the "Baseline" status of this feature ("paint-timing") as it will be tracked entirely separately as a new thing where it probably makes sense given different implementation status and goals.

[Elchi3]

Ok, so what's clear is that we should not add presentationTime and paintTime to this feature. Maybe we create another feature, but I guess this can be for another PR.

Yes, but I think in that case I would leave these two keys alone and not add them here. Keep them in draft and make the call about them at a later stage

[captainbrosset]

Makes sense to me. Removed!

[tunetheweb]

If we are adding a new feature it should probably be called "Paint Timing Mixin" as that's what defined these two time stamps.

It's maybe a little weird that it's technically part of the Paint Timing Spec, but a separate feature, then then that also reflects the reality that it was created later.

I'm just not sure how much the average developer cares about this to be honest. And if they do, they probably actually care who implements presentationTime and who doesn't. But if it's optional then it presumably wouldn't be part of that feature's core set anyway.

Unless we have two new features ("Paint Timing Mixin Paint Time" and "Paint Timing Mixin Presentation Time") but getting very in the weeds then...

[Elchi3]

LGTM. BCD should release today, so you could decide to leave this PR open and refresh the dist file once web-features upgraded, or you merge now and you will observe the baseline status change in the dependabot PR.