Skip to content
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

Move some definition of interactionID to UI Events #114

Open
npm1 opened this issue Jan 10, 2022 · 1 comment
Open

Move some definition of interactionID to UI Events #114

npm1 opened this issue Jan 10, 2022 · 1 comment
Assignees

Comments

@npm1
Copy link
Collaborator

npm1 commented Jan 10, 2022

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
Copy link
Contributor

mmocny commented Oct 22, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants