How to determine if events from CustomElements should bubble or not?

I’m trying to wrap my head around dispatching events from custom elements and whether they should bubble or not…

Take a look at this sandbox (that also has more details on my issue) and point me in the right direction:

What I’d like is for this doc about .delegate vs .trigger to be true also for our own events ( but it seems that if I want events to bubble but not cause unexpected runs of event handlers I’ll need to make the event name more specific for the particular custom element.

The whole thing seems a bit fragile… Let’s say I have two different custom elements with slot that expose an expanded event; How am I supposed to know that someone might nest these or how should they know they shouldn’t nest them? And if I want them to be nestable I’ll either need to not bubble the event or use different event names… Or the handler would need to do stopPropagation… It just seems like a complicated decision for each event to make, so is it easier to just force the use of .trigger for our own events (as I have until now)?

What would be the general advice if I were building a plug-in with one or more custom elements that expose events?

How big of a performance gain is it to be able to use .delegate vs .trigger? Is it so much that more specific event names is worth it?


For an event that I’m exposing to something other than an internal piece I allow it to bubble.

If i wrote an event for an element, like a listbox, there may be internal events that won’t be exposed,these I do not bubble

1 Like

@deap82 the issue you described is how the web work. By default, event will be propagated through the DOM hierarchy unless getting stopped. Because of such, you need to distinguish where an event originates from through event .target. Doing so could be tedious and muddle your business logic with UI code, that’s why we have self binding behavior to help with that. So your template would look like this

And your demo with the self binding behavior giving the expected results:

You can read more about self binding behavior here

If the above answers your Q and helps solve your issue, could you help improve the doc so that it makes more sense/easier to find?

1 Like

I never knew about “self”


That’s very interesting and surely a viable solution when you know about it. I still think though that for some types of events in some types of custom elements I should choose to not let them bubble and document that.

When it comes to the Aurelia documentation I think it would just be a matter of doing some cross references between these sections:

I’ll see if I can make a PR for that.

1 Like

choose to not let them bubble and document that.

That is what event.stopPropagation() is for, it’s determined by creation time of an event via { bubbles: true }. If needed, you can have some shortcut via custom attribute to stop a custom event from propagated, something like this:

<div stop-event="selected">
<div stop-event.bind="someDynamicName">


1 Like

I’m not sure I’m following; I just meant that just like focus and blur I too can choose to not bubble certain events and document that in our internal documentation.

1 Like