WHATWG on 2025-01-15

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.