jQuery Forum

http://dev.jquery.com/ticket/4072
I believe John liked it to when I mentioned it in the mailing list.
It was one of those things on my list of things missing in jQuery compared to the bad local framework I wrote for an app at work.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
mike.helgeson

I think it should just stop at the "context" of the jQuery object. So
you'd do this instead:
$("table").bind("click", function( event ) {
var $td = $(event.target, this).closest("td");
});
--
Brandon Aaron

That makes a lot of sense, except it does not work. The "context"
property of the jquery instance is always equal to the first element
when passing in DOM nodes. Unless I am mistaken.

Working or not, having public API methods rely on the context-property
doesn't seem like a great idea - is that the case anywhere else?
Jörn

Not to mention it would either be broken, or be a complete hack.
$(selector, context); is actually an alias for
$(context).find(selector); And this.context isn't what was passed to
context.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://daniel.friesen.name]
Jörn Zaefferer wrote:
> Working or not, having public API methods rely on the context-property
> doesn't seem like a great idea - is that the case anywhere else?
>
> Jörn
>
> On Wed, Jul 22, 2009 at 11:32 PM, mike.helgeson<mike.helgeson@gmail.com> wrote:
>
>> That makes a lot of sense, except it does not work. The "context"
>> property of the jquery instance is always equal to the first element
>> when passing in DOM nodes. Unless I am mistaken.
>>
>> On Jul 22, 4:33 pm, Brandon Aaron <brandon.aa...@gmail.com> wrote:
>>
>>> I think it should just stop at the "context" of the jQuery object. So
>>> you'd do this instead:
>>>
>>> $("table").bind("click", function( event ) {
>>> var $td = $(event.target, this).closest("td");
>>>
>>> });
>>>
>>> --
>>> Brandon Aaron
>>>
>>> On Wed, Jul 22, 2009 at 1:07 PM, mike.helgeson<mike.helge...@gmail.com>

I don't follow. What does "make the above .closest() context change" mean?
Jörn

Brandon mentioned making it so that you could do:
  $(Something, SomeContext).closest("div");
And closest would limit its search to within the context of the original $(...).
The problem is that:
  $(DOMElement, DOMElement)
Doesn't work right now (the context is ignored). Thus, we need to make it work. Incidentally, there was a proposal a while back to make
  $(DOMElement, DOMElementContext)
be roughly equivalent to:
  $(DOMElement).filter(function(){
    return $(DOMElementContext).has(this);
  });
If we were to implement $(DOMElement, DOMElementContext) we would also be able to access the DOMElementContext (in .context) inside .closest() - giving us the ability to implement
  $(Something, SomeContext).closest("div");
<br clear="all">--John

A big distinction between the two proposals is if DOMElement is not
contained in DOMElementContext:
$(DOMEelement,DOMElementContext).closest("body"); returns $([]);
$(DOMEelement).closest("body",DOMElementContext); returns $("body");
I vote for the 2nd argument.

Well specifically context is used in .live(). A .live() event handler
will be bound to the context. However, the .closest() method will look
beyond the context.
The context should limit the actions of jQuery to within the context's children.
--
Brandon Aaron

While what is being talked about here is confusing me, there are valid
uses for a method of restricting a .find based on a selector. That's a
feature I'd like to see.
$(NavFrame).find('.NavContent, .NavPic' /* some way of restricting to
outside nested .NavFrames */);
That being said, I don't like the context idea, to me a second
�erestrict�f argument makes the most sense. "keep options relevant to X
method in X method's arguments"
~Daniel Friesen (DanTMan, Nadir Seen Fire) [http://daniel.friesen.name]

> In what case would you want to find the closest() match but outside of a
> context?
$( this ).closest(".foo");
currently $( this ).context is equal to "this"
> What's the point of providing a context then if most closest()
> queries will just ignore the context away?
I don't think the context should be used for the enhancement I
suggested.

I have no specific use case in mind for that particular example. I was
thinking of the second "closest" argument would act like a break
statement rather than a search within context.
Still, If the context is used to limit the traversal of the closest
loop, how would you set the context of raw DOM nodes such that $
( event.target ).closest(".foo"); was still useful?

The point I am trying unsuccessfully to make is that the context
change will break existing code. It will make the specific context
required anytime raw nodes are used, which is probably the most common
"closest" usage pattern.
Instead of using the context, if a 2nd argument is added to the
method, it will not break any existing code, and it will be optional.
Maybe the solution could be a combination of the two? The argument
could be a boolean "useContext"?
$( event.target ).closest(".foo");
$( event.target, context ).closest(".bar",true);

Alright, the context sounds good, pardon my confusion.

wow, all this stuff sonds like a path finder AI algo a la "A*" (A Star) in a mono column grid with optional context as obstacle in the north direction ... did anybody of us think about some algo to quickly map the DOM in a 3D space? ... seriously, nested nodes are up in the Z scale, documentElement is the floor, and z-index a part, which is virtual, I would not be surprised if tomorrow somebody will splash down the DOM finding quickest way to relate nodes and distances ( sorry, I guess this glass of wine is not that good )
Regards