-
Notifications
You must be signed in to change notification settings - Fork 294
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Which target could we expose in Event Timing? #838
Comments
I don't think you've given enough information. To answer this one would need to know at least:
|
Which events: https://wicg.github.io/event-timing/#sec-events-exposed. Note that we expose first-input (where the types are a subset of those) always, and slow events. How are they dispatched: I don't understand this question. "They" = the events? I suspect the answer to that would be in the corresponding event's spec. How are they meant to be exposed: similar to other performance entries, we have a PerformanceEventTiming object which is exposed on a size-bounded array on the performance timeline and exposed to a PerformanceObserver, both of which are exposed to Window. In terms of the timing, we expose once the information on the update the rendering step after event handlers have ran, so that we can expose the 'next paint' after those handlers have ran. |
How they are dispatched is somewhat relevant as it could affect whether they leave the shadow tree or not. It also seems you'd have to patch all the places where they are dispatched in order to collect them for a report. |
That information can be obtained via event.composed, no? There's no need to patch all the places. When event.composed is false and the target is in the shadow DOM, we cannot expose a target so it should return null. |
How can you collect them without patching the dispatch places? |
They are dispatched from the DOM event dispatch algorithm, so again, that's the only thing that needs to change. What would I need to change from, for example, https://w3c.github.io/uievents/#event-type-mousedown? |
This is not an issue, but rather requesting some help to figure out how to integrate a new feature of Event Timing properly with DOM. We'd like to add the event's target to improve attribution of the API: see w3c/event-timing#9 or w3c/event-timing#60. I'm aware that we should only expose the 'top-level' Event target: if an event is re-targeted and there are targets in shadow DOM then those won't be exposed. However, I'm having a hard time parsing the event dispatch algorithm to understand which is the target I'd like. Is https://dom.spec.whatwg.org/#concept-event-dispatch only called once per event (and re-targeting happens internally), and hence
target
the object I want?The text was updated successfully, but these errors were encountered: