06:46
<Noam Rosenthal>
Noam Rosenthal: I'm quite confused by this message about nextEvent. If you init your event as cancelable then you can very well call preventDefault() on it, it even sets the return value of dispatchEvent(). Also I'm not sure how stop[Immediate]Propagation would be an issue for a nextEvent(), which I assume would be a kind of "after non-capture" phase, and would thus possibly only prevent other nextEvent() listeners. Or did you envision a second round of the whole dispatching with all 3 phases?
The issue I see would actually be with the return value of dispatchEvent(), and maybe it's what you were hinting at? Dispatchers could wait for one more microtask before checking the event's defaultPrevented but that seems indeed problematic that listeners don't know if the dispatcher will receive the info in time.
I haven't thought of all the details here, just that something that turns "once" events into promises could be useful in some scenarios
06:59
<Kaiido>
Yes, I completely agree, but I didn't understand the concerns you expressed.
07:40
<Noam Rosenthal>
Kaiido: I was referring to the fact that calling something like const event = await nextEvent("my-event"); event.stopPropagation() wouldn't work because the event would already have been propagated at that point
07:44
<Noam Rosenthal>

Thinking that nextEvent could return something PromiseLike instead of a Promise, with both then and e.g. preprocess
So

or something where the then is synchronous, e.g. const event = await nextEvent("name").then({ e => e.stopPropagation(); return e; });, and await nextEvent("name") would just work. Though we can probably come up with better ergonomics

08:11
<Kaiido>
But you could still prevent the propagation to the next handlers added through later nextEvent(). It's basically like how you can't expect stopPropagation() in the bubbling phase will prevent the handlers in the capturing phase. It makes sense that nextEvent() would be its own phase.
08:33
<Noam Rosenthal>
Kaiido: sure, it's a potential way to look at this.
17:59
<annevk>
Dominic Farolino: smaug probably recalls the rationale for not draining microtasks when JS is on the stack. I don't. In any event we might want to clarify it in the HTML standard.
18:07
<smaug>
The whole point of microtasks is that they are handled at the end of outermost script execution. The idea being that it is effectively end of "your" script when your MutationObservers are handled. Big(gest) reason for that is performance, basically trying to batch as many mutations as possible, yet not mix microtasks from different event listeners or so.
18:11
<smaug>
Microtasks were designed for MutationObserver, and I'm not sure anyone ever really thought through how well they work with Promises and such (Promises started to use them later). Microtasks were possibly just good enough for Promises. And it would have been probably quite confusing to have microtasks for MutationObserver and something almost-microtasks for some other use cases.