Re: [whatwg/dom] Proposal: asynchronous event listeners (Issue #1308)

> async callback added as listener

Someone might very well want an "async callback" for convenience of accessing `await` syntax, but still have it behave perfectly normally.  The sync/async nature of the callback could never be "the signal" of how the default action behaves.  (besides your point that non-async functions can still return promises)

> if other listeners were added without such option

I think the entire goal here is for some listeners to still opt in to synchronous dispatch (as today) and some others to opt in to async dispatch (as if calling `scheduler.yield()` or `scheduler.postTask()` immediately from the event listener.

> there should be still a way to prevent events from never resolving

At the moment, there would be no awaiting of any promise for any default action as part of this specific proposal.

Such ideas *were* discussed, i.e. could you literally delay the default action, such as a form submit, waiting on a server hop-- or even just a local postTask while still allowing paint-- but that is *not in this specific proposal* at the moment, I think.

I tried to [list related use cases in a comment above](https://github.com/whatwg/dom/issues/1308#issuecomment-2312993127) in order to help disambiguate.  There was a lot of [good initial conversation at TPAC 2024](https://github.com/whatwg/dom/issues/1308#issuecomment-2377284078) about these use cases and potential proposals for each of them. 

But again, the specific scope of this proposal here I think is limited to the "passive events" use case.

Obviously we could create other proposals to handle the other use cases-- I'm also eager to see more of this area being improved.

> I find that ~300ms a sweet spot

So, I think that 300ms is too long to provide a default feedback to the user.  However, if there is a "passive listener" it might very well be acceptable for it to take hundreds of ms or even multuple seconds to resolve, so long as those actions are more like "optional followups" rather than immediate feedback.

---

> bubbling, capturing

This is an interesting question.  I wonder if these types of events should participate in the same type of bubbling/capturing.  If we do both sync and async event dispatch that might mean more total tree walking.


-- 
Reply to this email directly or view it on GitHub:
https://github.com/whatwg/dom/issues/1308#issuecomment-2488877114
You are receiving this because you are subscribed to this thread.

Message ID: <whatwg/dom/issues/1308/2488877114@github.com>