Re: [whatwg/dom] Allow custom activation behavior to be added to an event (Issue #1320)

@jakearchibald I see. Another example is `HTMLElement.click()` on a `<summary>` element, in relation to the `toggle` event on the parent `<details>` element. The `toggle` event is non-cancellable and emitted after, during the activation (but before the next frame, I think?).

I suspect we would see people use `event.addActivationBehavior()` also on non-submit buttons and JS-only forms, where there is no default behaviour, as a way to wait for the user's JS application to have finished doing something and thus register a "late" or "after" listener. Is that something we want to encourage? Basically a way to express priority or ordering between event handlers.

I see this come up a fair bit in developer code at Wikimedia, where event+timeout is used as a way to plug into something at a point where there is no DOM event or app-provided callback (yet). Even more so in asynchronous code, where the synchronous assumptions by event handlers (apart from eg. in Service Workers), would be insufficient anyway. Because `fireEvent` naturally would not wait for the completion of any async `addEventListener(async function…)`. In this case we also tend to see, eventually, given a large enough code base, code that nests two setTimeout's in order to implicitly wait for another handler that does one setTimeout and/or is async. It's an arms race.

For simple one-to-one and synchronous use cases, `event.addActivationBehavior()` would allow decoupling and coorporation between event handlers which is great. For the more complex cases, it seems `event.addActivationBehavior()` might underfit. B would perhaps be coupling and assuming specific things about what A will have done by then. This would be an unstable contract and likely insufficient. It's not uncommon to see B "chase" A (e.g. attach to click, change, submit, and whatever else may trigger the same application behaviour). In such a situation, would we recommend developers instead emit their own non-cancellable DOM event and/or JS callback, to represent the logical application behaviour?

If so, I wonder if the the platform should follow that pattern too? We have this for `toggle` and for a few other things like it. I would consider `pageshow`, `pagehide`, `unload` to fit in this category as well. They emit regardless of how something it happens, it just happens. I can't think of a good name for click and submit activations, but perhaps a non-cancellable `activateclick` and `activatesubmit` event would make sense (better name welcome!). This would behave very similar to your example, except for the callstack which would presumably be after `button.click()` has completed in the next tick. Or not? I mean, nested events do exist right? E.g. we have change/blur/focus which afaik involve some nesting where a single behaviour trigger ends up synchronously emitting multiple events. Either way makes sense, but if it's a requirement that it happen as part of `element.click()` then perhaps that would be the better choice.

The reason I'm saying all this, is because I think re-using the event system is easier to learn, easier to extend and adopt for applications with their own events, scales to async behaviours, and perhaps also easier to integrate into frameworks and abstractions that already understand events.

I also see value in being able to listen to these through propagation, without needing to attach a synchronous listener to (one or more) possible earlier events that lead to the activation. Think about scroll events and the jank they caused. In other words `addActivationBehavior()` during `click`, vs listening for `activateclick`. It's probably a micro-optimisation in the case of click, but I like the declarative nature of this and the performance potential it has.

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

Message ID: <whatwg/dom/issues/1320/2474037035@github.com>