Expose INP target element as first class citizen in attribution

[just-jeb]

Background

We use the INP target element instance for gaining additional insights on it upon onINP callback.
The info we're getting is mostly the element location in DOM tree and its relation to the parent elements, which, in turn, helps us understand the element's attribution to specific application/widget within the website.

The issue

As of web-vitals@4.0.0-beta.1 we have to get the target by accessing metric.entries and choosing the right entry.target. For this to be aligned with what web-vitals expose as INP target selector we have to use the same logic as in web-vitals. Today it takes the first entry with a non-null target, because of a Chrome bug. Once the bug is solved the logic for target element selection will probably change to get the first entry (metric.entries[0].target) and then we'll have to change it in our code as well.
If fact every time this logic changes (even though unlikely), we'll have to update our code as well, which makes it a leaky abstraction.

Proposed solution

Expose INP target element as a first class citizen in INP attribution.
This way the alignment between INP target selector and INP target will be abstracted away from the user and if/when the logic changes it will only have to change inside web-vitals.

[mmocny]

No strong opinions on the shape of the api in this library, or this request.

But just pointing out that:

• A single interaction might have multiple targets. For example, dragging cursor (i.e. for text highlighting) might have a different start target (down) and end target (up).
• A single animation frame (the thing reported by LoAF) might have multiple distinct interactions (or other, non-interaction event timings) with different targets.

For this reason, abstracting away the list of entries down to a single target might sometimes be lossy.

[tunetheweb]

Yes but we already expose the target (in both v3 and v4) as a selector text string so do make a choice here.

The ask is to also expose it as an element so if you want to do some other stuff you can. Like web-vitals-extension prints it to the console so it can be used to highlight the element on hover, and view it in the Elements panel. We thought that was the only use case so decided NOT to add it just for that. But now seems we have at least one other use case here.

Would be interested if we had a third use case to really make the case for including it in the library.