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

I haven't seen updates after late September but there is one option that hasn't been discussed: the usage of `{ async: true }` as third argument field:

  * it can help disambiguating more than an async callback added as listener, because even a sync callback could return a *Promise*
  * it can easily fail down the path if other listeners were added without such option *but* ... if there is only one listener for that specific node (node ownership via library/FW/utility) it helps branching logic without affecting the rest, delaying eventually the bubbling, so that capturing could prevent those listeners to ever happen but if inner-node has one or more async listeners attached, it can decide when the rest of the bubbling could happen, if ever
  * there should be still a way to prevent events from never resolving, so that this behavior could be related to a MAX_LISTENER_TIME defined by vendors

Once upon a time, we had `click` events triggering after ~300ms because `ondblckick` event could've also happened in the meantime, these days that delay has been mitigated but I find that ~300ms a sweet spot that makes events more convoluted **only** if an explicit `{ async: true }` has been provided.

This idea is still about branching events in a way or another, but to me it feels like the least obtrusive approach:

  * fully backward compatible with all the Web that never used such property as optional third argument field
  * it doesn't change anything in those pages where such property never exists
  * it helps libraries' authors to define listeners on specific nodes which *asynchronicity* is crucial to better operate

Any thought about this option? Thanks.

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

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