w3c / event-timing

A proposal for an Event Timing specification.
https://w3c.github.io/event-timing/
Other
44 stars 13 forks source link

Move some definition of interactionID to UI Events #114

Open npm1 opened 2 years ago

npm1 commented 2 years ago

Our definition of what constitutes an interaction could be useful more broadly. I would need to give some thought on which parts we can move while maintaining the core logic in this spec.

mmocny commented 2 weeks ago

Another potential option is User Activation. Right now this seems very under-specified, but, its described as:

user agents allow these APIs only when the user is actively interacting with the web page or has interacted with the page at least once.

According to MDN

A user activation either implies that the user is currently interacting with the page, or has completed an interaction since page load. User activation can be triggered by a button click, pointer touch, or some other user interaction with the page.

It might be interesting to evaluate how much overlap there is, and, if there would be interest in aligning. A quick audit of chromium shows there are a lot of hooks that set the UserActivation bit-- more than we're interested in. Clearly not all of them are "Event Timing Interactions", but, maybe events that trigger setting that bit are interactions?


Regarding UI Events: this seems like a sensible home, but, event dispatch is inherently synchronous, while labelling Interactions is (potentially) asynchronous. Its possible UI events can expose hooks, but may not be able to include the data inside the event dispatched.

On the other hand Pointer Events spec seems to already has to do a lot of this type of work (i.e. to manage active pointer / active button states, for e.g. pointerId), as well as already has to track pointercancel conditions.