jQuery.load is an incredibly useful method, but if you want to do more with the returned source than put it into a div then you may want to use jQuery.ajax directly with your own callback.
The source code for the load method is a great starting point for writing your own callback, in particular how the 'done' callback selects the items to append;
jQuery("<div>").append( jQuery.parseHTML( responseText ) ).find( selector );
This is most likely what you're looking to amend by using your own callback. The parseHTML method creates an HTML fragment and then appends it to a div (this div is an orphan, it is never inserted into the DOM).
You may, for example want to run two selects;
tempDiv = jQuery("<div>").append(jQuery.parseHTML( responseText ));
someResult = tempDiv.find( selector1 );
someOtherResult = tempDiv.find( selector2 );
With every release of iOS there tend to be some gremlins lurking in Safari, iOS 7 was no different.
When first testing the site I've been building in iOS 7 I was getting a failure when resubmitting an AJAX POST request, the response was 412 (Precondition Failed).
Eventually I found this issue explained related to a MooTools issue.
"Safari responds to etags properly and adds "If-None-Match" and "If-Modified-Since" headers to another request for the same file. This makes Apache respond with a 412 status (Precondition Failed) as it should do for "post" requests (according to RFC 2616)."
"Unfortunately Safari doesn't then deal with the 412 as it does with a 304 (Not Modified). It doesn't grab what it has in the cache and put it in the response, it gives you nothing."
The date on that blog post is 04/12/2009! There is no sign of this issue in iOS6 so maybe it's slipped through the iOS cracks and will be patched
The Fix? Switch to GET and Safari will deal with the request correctly.
Recently I've been doing quite a lot of work with Bing Maps. Not every page on the site requires the map API so we've been attempting to use require.js, which we already have, to maintain that dependancy.
As usual it's more complicated than we'd hoped. Bing Maps provides a callback hook that we can use with the async plugin of require.js, however the callback fires before the maps are actually ready to use. The Microsoft object is defined but the Maps and Location objects are not. This led us to implement polling to check for these properties before resolving a deferred.
Why this is bad: The require module is now returning a promise rather than the maps declaration that you might expect to be returned. In practice this is manageable because by using the deferred our code can continue regardless of the Maps loaded state.
I've created a sample Gist of how this can work, although for production you may also want to handle the failure case and reject the deferred.