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 <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.
>
> 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 prototype-scriptacul...@googlegroups.com.
To unsubscribe from this group, send email to 
prototype-scriptaculous+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/prototype-scriptaculous?hl=en.

Reply via email to