> Sorry, but I don't follow the logic. What stops us from using
> `getElement` with optional selector?
That meant adding another method. We had chosen to avoid that.
(Remember Event#findElement already existed).
> Maybe it's just the way my brains
> are wired, but `findElement` for me is associated with traversing or
> searching something (i.e. "find" verb). It feels strange to say - `var
> targetEl = e.findElement();` when my intentions are not to _search_
> for something, but merely _retrieve_ it.
Well, both Evemt#element and Event#findElement without argument often
return the element that's right above the target node (which as per
specs can be a textnode). So whether or not we're finding vs.
retrieving is questionable, but I get your point.
> Even better would be to replace both - `element()` and `findElement()`
> with `getTarget()` which would accept optional selector. It's shorter
> and conveys intention better; it actually describes that it is event's
> *target* that we are retrieving here, not just some vague *element*.
I think Event#getTarget is ambiguous too, as we don't return the
target node but the first node above it that's an Element.
> What do you think?
As I said in my previous comment, worth discussing in the context of
Sam's upcoming work on Element#on.
FWIW, I'm not particularly sold on the name of Event#findElement
myself, but it happened to be already part of the API.
It made sense to extend it for the reasons I explained above. And it's
unquestionably much better than Event#element.
You received this message because you are subscribed to the Google Groups
"Prototype: Core" group.
To post to this group, send email to firstname.lastname@example.org
To unsubscribe from this group, send email to
For more options, visit this group at