06:46 | <Noam Rosenthal> | Noam Rosenthal: I'm quite confused by this message about |
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 or something where the |
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. |