Why do the xforms-select and xforms-deselect elements bubble?

Question

According to the XForms specification most events are said to "bubble".

As per the DOM Level 2 Event Specification an event that "bubbles" means that the handlers for this event associated with ancestor elements of the event dispatch target will also receive this event.

For an event to be specified as "bubbles" it means the xf:dispatch action cannot modify the bubble behavior to limit it to the target.

I don't understand what the benefit is of so many xforms events to bubble. For example, xforms-select and xforms-deselect. They apply to xf:item (of xf:select*) and xf:case (of xf:switch, i.e., used in a form with tabs).

Let's say I have an xf:case with an xforms-select handler that will cause a refresh on an expensive rendering widget, just when the tab is actually selected rather than every time the model is updated. Now I also have an xf:select in that same tab. Now whenever the user selects another item in that selection, the xf:case would receive the xforms-select at the bubble phase, doing the costly update operation every time.

This doesn't seem to make sense.

In fact xforms-node-attached has it right: we really want to be specific as to which form element gets the node attached. But apart from that, most events are said to bubble.

I could conform myself better with this issue if I understood the reason for this. Otherwise I am tempted to change my XForms engine to change the definition of xforms-select and xforms-deselect not to bubble.

Answer 1

This is to allow what is known as event delegation:

"Event delegation refers to the process of using event propagation (bubbling) to handle events at a higher level in the DOM than the element on which the event originated. It allows us to attach a single event listener for elements that exist now or in the future." (from an older version of this jQuery doc page)

In general, this is a good thing:

• You use less event listeners.
• A listener can listen on multiple targets.
• You don't need to remove/add listeners as DOM elements are added/removed.

It seems that, in the HTML world, things have moved towards letting everything bubble. For example, the old focus event didn't bubble, and the newer focusin event bubbles.

If you have an event handler which gets activated by events dispatched to multiple targets, in some cases you need the ability to discriminate. This is where event context information is useful. Libraries like jQuery also allow you to associate an event handler filtered by CSS selector, which is neat.

Now in the case of xforms-select specifically, your issue is that you cannot discriminate between this event dispatched to an xf:case vs. an xf:select. This might mean XForms shouldn't have a single event for these two scenarios, or it should have enough event context information to discriminate between the two. I don't think that this is making a case for not letting the event bubble.