jQuery Forum

I have run across a browser inconsistency which is not corrected for
in jQuery. This may be on purpose, but I was wondering if it's
something that should be added as a bug?
<script>
$(document).ready(function(){
alert($("#foo:empty").length);
});
</script>
<div id="foo"><!-- This is awesome! --></div>
---------------
In IE, that will alert 0, because it treats the comment as a child
node (though I haven't figured out with jQuery how to access such a
node in any meaningful way.
In FF, it alerts 1, because it sees #foo as indeed empty (ignores the
comment altogether).
Should jQuery correct for :empty checks where the only child node(s)
is/are comments? Seems like treating comments as actual node content
is problematic.
I recently ran across an even weirder instance of this issue, where IE
actually adds a comment as a child of a preceeding LI element if it
appears in a UL:
<ul>
<li></li>
<!-- i love commenting -->
<li>this is cool</li>
</ul>
The :empty check will fail on that first LI in IE, but will work in FF.

When I am logged in, and I search for one of my plugins by name (in
this case, "mpAjax"), I get an error that says "validation error". But
when I search for the same plugin by name not logged in, the search
works fine. Thoughts?

I have a case where I wanted to open modal "B" from the onClose
handler of modal "A". This works fine, but then the "close" button of
modal "B" fails to function properly. However, if in the onClose
handler, i simply do a setTimeout(...,0) to delay the re-opening of
the modal until immediately after the onClose handler finishes, and
everything works fine.
Are you aware of this problem/bug/limitation?

I'm excited about the new XHR registry plugin coming out with the next
jQuery release. I have taken a stab at writing a plugin to adapt
jQuery for use with a custom XHR implementation called flXHR (http://
flxhr.flensed.com/), which allows authorized cross-domain
communication.
Here's a link to a working demo: http://flxhr.flensed.com/code/dev-tests/test-jquery-xhr.html
The plugin itself is located here:
http://flxhr.flensed.com/code/build/thirdparty/jquery/jquery.flXHRproxy.js
The strategy I took with this was to create a simple way for an author
to "register" a particular URL for use with this custom flXHR
transport, associating with that target URL a set of custom options
for the transport object to use.
In this way, an author could have multiple different URL's that they
targetted, and each one could have its own set of configuration
options, and the plugin would take care of matching it up at the time
of the request based on matching the target URL.
I was wondering if anyone would be willing to take a look at the
plugin I wrote and offer any advice on if the code is good or
compatible with jQuery, or on what steps it might involve to have this
plugin join the official ranks of jQuery, etc.
Typical usage might be:
jQuery.ajaxSetup({transport:'flXHRproxy'});
jQuery.flXHRproxy.registerOptions('http://www.mydomain.com/',
{xmlResponseText:false...});
jQuery.flXHRproxy.registerOptions('http://rss.mydomain.com/',
{xmlResponseText:true...});
...
jQuery.ajax({url:'http://www.mydomain.com/something.html'...});
...
jQuery.ajax({url:'http://rss.mydomain.com/feed.html'...});

I'm excited about the new XHR registry plugin coming out with the next
jQuery release. I have taken a stab at writing a plugin to adapt
jQuery for use with a custom XHR implementation called flXHR (http://
flxhr.flensed.com/), which allows authorized cross-domain
communication.
Here's a link to a working demo: http://flxhr.flensed.com/code/dev-tests/test-jquery-xhr.html
The plugin itself is located here: http://flxhr.flensed.com/code/build/jquery/jquery.flxhr.js
The strategy I took with this was to create a simple way for an author
to "register" a particular URL for use with this custom flXHR
transport, associating with that target URL a set of custom options
for the transport object to use.
In this way, an author could have multiple different URL's that they
targetted, and each one could have its own set of configuration
options, and the plugin would take care of matching it up at the time
of the request based on matching the target URL.
I was wondering if anyone would be willing to take a look at the
plugin I wrote and offer any advice on if the code is good or
compatible with jQuery, or on what steps it might involve to have this
plugin join the official ranks of jQuery, etc.
Typical usage might be:
jQuery.ajaxSetup({transport:'flXHR'});
jQuery.flXHR.registerOptions('http://www.mydomain.com/',
{xmlResponseText:false...});
jQuery.flXHR.registerOptions('http://rss.mydomain.com/',
{xmlResponseText:true...});
...
jQuery.ajax({url:'http://www.mydomain.com/something.html'...});
...
jQuery.ajax({url:'http://rss.mydomain.com/feed.html'...});

I was playing around with the new XHR plugin system that will be out
with 1.2.7/1.3, and I noticed something that seemed a little odd to
me.
I was using the ajaxSetup() function to change my transport, but I
wanted to chain off the end of that call, and it doesn't work, because
apparently ajaxSetup doesn't return the "jQuery" object.
I had been reading and trying to diligently follow the Plugin
Authoring guide here: http://docs.jquery.com/Plugins/Authoring
which says: "Your method must return the jQuery object, unless
explicity noted otherwise."
Perhaps I'm missing something, and if so I apologize, but I would have
expected ajaxSetup to be chainable since it's API definition doesn't
*explicitly* say it isn't. Is this a misunderstanding on my part, a
documentation deficiency, or a possible suggestable improvement to
ajaxSetup?
Is there a reason why ajaxSetup shouldn't be chainable?

I've got a project I've released which is a drop-in replacement (100%
API compatible with) of the browser's native XHR object. It
implements full cross-browser functionality, but with the familiar
API. The primary design reasoning for this was that I wanted my
project to be able to be easily plugged-in/adapted to the major JS
frameworks (jQuery, Dojo, Prototype, etc), since they all use XHR
somewhere inside them.
My problem has been that the other frameworks provide a small utility
function which they use to generate the XHR instance that they then
use. So, adapting to use my object is easy, I just have to override
the appropriate function and have it instantiate mine instead of the
native one. This has worked beautifully with Dojo, ExtJS, Prototype,
and YUI.
However, to the best of my inspection abilities, it appears that
jQuery has no such separate function for the XHR object instantiation,
but is instead inside of a much bigger, more complex function called
"ajax".
So, my adapt approach wouldn't work here unless I was prepared to re-
invent nearly all of the logic inside that function, which is a really
bad idea in my thinking.
I guess I could take the source of the function, convert it to a
string dynamically, regex replace, and then re-eval... but that is
INCREDIBLY ugly to do.
So, my question is, does anyone have any thoughts on if jQuery could
be extended this way? Or am I going to have to re-invent the "ajax"
wheel to get my object working inside jQuery?
Is there any chance that jQuery dev would consider moving the XHR
instantiation out into another "factory" function, like the other
frameworks do, so it could more easily be altered?