> 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. Best, Tobie --~--~---------~--~----~------------~-------~--~----~ 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 prototype-core-unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/prototype-core?hl=en -~----------~----~----~----~------~----~------~--~---
