I don't think you understood my question. I understand that event
delegation means that events bubble up from the element the event
actually occurred on, to the ancestor element that the event
[listener] was attached to. And that the events that reach that
listener / handler are filtered based on the selector specified. And
that the element returned is the ancestor of the element where the
event originated. However, I did not expect to get events where that
ancestor element was ALSO an ancestor (not descendant) of the element
that the handler was attached to.
ele_matching_selector ... ele_with_handler ... ele_triggering_event
So descendant elements of ele_with_handler can trigger events, and the
handler sees them. However, when using a selector, events on elements
that do not [match themselves] or have an ancestor matching the
selector get 'suppressed' before reaching the handler. I would have
expected that if there was a matching ancestor, but that ancestor is
outside the 'scope' of ele_with_handler, that the event would also be
The way it works now, if an ancestor of ele_with_handler matches the
selection condition, no event filtering will occur for events on
descendants of ele_with_handler.
On May 29, 6:13 pm, Tobie Langel <tobie.lan...@gmail.com> wrote:
> > The same thing happens for other 'delegated' events. Is
> > that the intended functionality?
> Yes. That's the very definition of event delegation.
You received this message because you are subscribed to the Google Groups
"Prototype & script.aculo.us" group.
To post to this group, send email to prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to
For more options, visit this group at