Consider exposing event target ID (for cases where target is detached)

[mmocny]

Event Timing Entries report a target attribute, which runs the get an element algorithm.

This will return null in cases where the element is detached from document at the time the getter is called. This is especially problematic in cases where an Interaction modies the DOM, removing the element that was just interacted with, and the Event Timing PerformanceObserver doesn't fire until later. In such cases, there is no window of opportunity to read metadata about the event target at all.

The typical solution to this is to register an event handler and collect metadata about it during event dispatch -- but this has a potential performance cost during a critical moment of user experience.

We should consider capturing and exposing the event target id attribute to Event Timing Entries, which could persist even when the Node unavailable.

[yoavweiss]

As we're already doing something similar for Element Timing, this seems easy enough to both justify and add.

I'd be curious to hear from @nhelfman if this would help tackle some of the use cases that he and his team have been running into.

[nhelfman]

For my team it will help with identifying DOM elements which have not explicitally tracked user interaction. Typically this is not necessary since for each interaction we care about we keep a map of the event timestamp to correlate with the event timing entries and use a specific tagging label.

When we process the events we collect event timing entries which we don't have a tracking in the map and aggregate them seperately as "untracked". To diffentiate between them we lookup the target DOM element id and use that as key for this tracking group. This helps us better understand which interactions we are not tracking and tagging explicitally.

For the cases the DOM element has been detached likely have a blindspot.

[mmocny]

Thanks for the feedback! I didn't realize that we do this for Element Timing, will take a look at that.

[mmocny]

Element Timing uses an attribute just named id which is describing the attribute named element.

I am not sure if for Event Timing it should also just be id or needs to be targetId.

(I also notice that the "get an element" algorithms are duplicated across specs and maybe could be refactored into performance timeline or something)

[Ludovic33Fr]

Hello,

We are working on a RUM based on the vitals web API and we noticed that our users (mainly retail) have the same concern. Namely the main contributors on the INP have the target field set to null. It is a pity not to have the persistence of the selector, because it is difficult to identify slow interactions. The identification of the DOM at the time of the interaction natively in the API would be very useful, because as it is, we note that the system in place allows to make the identification only in half of the cases approximately

[mmocny]

Thanks for the feedback!

I was actually playing around with this recently and stumpled on Event.composedPath() which returns an array of nodes which will receive the event (due to bubbling/capture).

I think that will become even more valuable to cross reference than just the target itself.

[mmocny]

After a bunch of iteration of feedback, we have decided to expose a very simple value:

• id=, and/or name= attribute, only

This is easily actionable by a developer, and provides immediate value, without having to solve a bunch of issues.

---

Element Timing already exposes id, but not name.

Layout Instability API also exposes nodes, but doesn't expose any other information.