After looking at the source it looks like if we made the document a jQuery property instead of a private variable we could make jQuery document-aware relatively easily.

At the top of jquery we've got:

var document = window.document;

We can change that to:

jQuery.document = window.document;

then update all references to document to point jQuery.document instead and then add the following to jQuery.sub

    sub: function(document){
        /* ... */
        jQuerySubclass.document = window.document || jQuery.document;
        /* ... */
    };

There may be some issues with even binding and we may want to make window a jQuery property in order circumvent those issues also.

DaveMethvin pointed out that there may be some memory-leak issues when "remote-controlling" an iframe this way if the iframe is closed or navigated to another page.

Also, Sizzle will need to be updated to allow for setting the default document (context).

Let's bring this up for discussion again for 1.7.

Nominating ticket for 1.7 discussion.

+0, I would prefer to explore jaubourg's "newInstance" approach

-1, sub is not the right means to do this. Internal caches will be shared and we know where this would lead.

+0,

+0, Not sure how this will help, not sure when .sub is useful.

+0, I think it's probably ok if we don't push for this.

Oh well, it looks like this one isn't going to make it.

I'll make one last stand for it, though...

I suggested using $.sub, but it doesn't really matter to me. I'd just like a document-aware jQuery. Here is my use case:

I've got a in-browser "intranet" browser. This HTML5+CSS3+jQuery browser runs fullscreen in webkit/firefox and it has all of your normal browser bells and whistles - like tabs (via iframes), an address bar, back/forward/refresh buttons, etc. All of the intranet web-pages "initialize" jQuery as follows:

if(!parent || !parent.jQuery){

document.write("<script src='jquery.js'></script>"); // </script should be escaped in the real world.

}

else{

$ = jQuery = parent.jQuery.sub();

}

...which is pretty useful little trick. The draw back is that the intranet iframes can modify the parent's jQuery object...which could potentially break our application. This is mostly fixed by $.sub (though I imagine different document modes could cause issues with $.support, but I'm not sure). The only other obvious issue is that all jQuery selectors need to be aware of the iframe's document, which is doable, sure...but pretty annoying.

So yes, it's an edge-case...but also a really cool way to re-use a script resource without have to re-parse and re-execute it.

+1, It would be really nice if there was a generic way to always make jQuery calls relative to another document, instead of having to flood context arguments