element.closest(selector, container)

[caub]

It's rare but sometimes you have a reference to a container node, and want to search for the closest element match in this container, adding a second optional parameter may be interesting (either to make sure to limit the search to a subtree, or for performance reasons)

it would just be a second parameter in this function as a stop condition of the for loop
https://code.google.com/p/chromium/codesearch#chromium/src/third_party/WebKit/Source/core/dom/SelectorQuery.cpp&sq=package:chromium&l=157&dr=C&rcl=1455121616

[hzr]

This has been filed as an issue before, but was closed due to lack of interest: https://www.w3.org/Bugs/Public/show_bug.cgi?id=26841

You can always do something like this:

const closestEle = ele.closest(".blah");
if (containerEle.contains(closestEle)) {
   ...
}

This does not have the performance benefits, but I doubt closest() being a bottleneck, ever.

I'm not really opposed to it though, personally. I use the above pattern every time I use event delegation.

[caub]

ok thanks

[tjcrowder]

Please consider reopening and actioning this. closest as a DOM feature is only now coming into many people's consciousness. While there may have been lack of interest in 2014, there's clear interest in 2016 (this issue) and 2017 (my finding this being puzzled by the lack of a second parameter).

The second parameter is useful in event delegation:

myTableBody.addEventListener("mouseover", function(e) {
    var el = e.target.closest("td", this);
    if (el) {
        // ...
    }
});

while contains can be used, it's less clear and less efficient (granted, the efficiency is a minor point):

myTableBody.addEventListener("mouseover", function(e) {
    var el = e.target.closest("td");
    if (this.contains(el)) {
        // ...
    }
});

It's just mentally awkward to say "See if any ancestor is an X -- oh, but wait, I only want ones that are within Y."

Prior art: jQuery's closest does indeed have this second parameter: http://api.jquery.com/closest/#closest-selector-context

Specification and development cost seems low relative to the clarity and simplicity, esp. as this is still a new thing.

[annevk]

There is #215 to improve event delegation. Maybe if that doesn't pan out we should reconsider this.