> 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 prototype-core@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to