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 suppressed. 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 <[email protected]> wrote: > > The same thing happens for other 'delegated' events. Is > > that the intended functionality? > > Yes. That's the very definition of event delegation. > > Best, > > Tobie -- 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 [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.
