jQuery Forum

A recent commit - http://github.com/jquery/jquery/commit/04524287d3e0112deae570ff9247c734833431bb
- changed the behaviour of $() from $(document) to $([]).
This is a change that I can truly jibe with, and I think the behaviour
makes sense. No one likes having to do $([]) to create an empty jQuery
object. Unfortunately, no change for 1.4 has made me think "will
break a lot of people's code" like this one. For some inane reason,
people (and a lot of tutorials) really started using the $() shortcut,
so the change kind of makes me somewhat uneasy.
Would love to hear any other perspectives on this. Should the change
stay in and be loudly shouted as a potential 1.4 transition issue, or
rolled back?
--

Not sure if this merits a ticket because it ventures off into the
world of "things that people don't actually do," but I figured it was
at least worth a mention.
in jQuery 1.3.2
var foo = $("<div><span>foo</span></div>").parent() // returns a DIV
wrapped with jQuery, and accordingly
foo.find("span").length === 1;
in jQuery 1.4
var foo = $("<div><span>foo</span></div>").parent() // returns a
DocumentFragment wrapped with jQuery, and accordingly
foo.find("span").length === 0;
I'm not sure if this piques anyone else's attention like it did mine.
Getting to behave the same would require getting .find() to work
directly on DocumentFragments instead of their .contents(), which I am
less than sure is a priority.
--adam
--

I posted this comment to the PBWorks wiki a few days ago, but it got
deleted without being addressed at all. I'm all for keeping the wiki
neat and contained after comments are addressed into the spec, but
overzealousness in this matter can really be a hindrance to
participation and communication....
I was curious as to how ListBuilder is going to integrated with
Autocomplete. Mark's original plugin simply required
.autocomplete().tokenlist()
however, in keeping with the way that draggable/resizable is set up on
Dialog, I proposed something along the lines of
.autocomplete({listBuilder:true})
I'm not sure if this is the *best* solution or not, but it is
consistent in a sense.
My real point is that jQuery UI is both loved and hated by many
developers worldwide, but I don't think anyone thinks that one of the
core problems affecting the library is that comments linger on the
development wiki for too long.

Over the years there has been considerable interest in providing
conditional chaining functionality to jQuery, though nothing has ever
been cemented.
http://groups.google.com/group/jquery-en/browse_thread/thread/43a69fa41f6e7089/6cebfee318992fe6
http://groups.google.com/group/jquery-dev/browse_thread/thread/d82ea6dcdc9f0ab/e6be92f209194363?lnk=gst&q=ifelse#e6be92f209194363
"Cowboy" Ben Alman has just released another implementation of this
method on his blog, http://benalman.com/projects/jquery-iff-plugin/ ,
and I wanted to direct everyone's attention to it, in order to revive
discussion of the possibility of including if (and else?) methods to
the jQuery core.
In the past there has been a great deal of wrangling about the
implementation of this logic, but I'm of the mind that it is time to
get the cart out of the horse's way on this one...

With the advent of native JSON support in browsers forthcoming, should
jQuery.support check for the existence of the JSON obj and use it as
the preferred way of parsing JSON whenever the library needs to do
so? This would have the added benefit of leveraging json2.js for
users who already have that library in use on sites with jQuery.
--adam

Were there any changes to the way Tabs is supposed to work between RC5
and RC6? I have a few sets of Tabs in my application, and one set of
nested tabs, which works fine in rc5, but in rc6 doesn't set up
properly in IE. Things get even worse when I build from the current
trunk in SVN, the content isn't visible at all, and the interaction
doesn't bind at all in either FF or IE, so I'm assuming that's not
ready for prime-time, which is fair.
Can anyone provide some insight into any changes that might have
happened? I rolled a theme on rc5, were there changes to the CSS
framework betweeen releases? I've been wrestling with jQuery/UI
versions all day between this and the 1.3.1 doc ready bug, which is
"fixed" in the nightlies > 6170 but completely breaks my app in IE.
The code in question, fwiw, is this:
$("#winlose_tabs > ul,#winners_tabs > ul,#losers_tabs > ul").tabs
();
    $("#winners_tabs,#losers_tabs")
    .find(".ui-tabs-nav")
    .bind("tabsload",function(e,ui) {
        $("table tbody tr:odd",ui.panel).addClass("odd");
        $("td.wldesc",ui.panel).shortenify({chars:20});
    });
I could, and probably now will, fix up the theme css to see if that
fixes things, but I'm posting this thread because the bottom line is
that with constantly changing versions and release candidates and a
very fluid development schedule forjQuery and jQuery UI., these subtle
API changes (extra wrapper in accordion added in RC5, etc.) are an
absolute nightmare for those of us trying to keep our code in sync.
---adam

It would be useful to be able to use the .index() method to find the
index of the current element in a given set, rather than the current
implementation (searching the current set for a given element), which
forces the developer to do gyrations in order to find out a simple
piece of info.
For instance
$("#sometable th img").click(function() {
//find out index of img's parent <th> in its own <tr>
var $th = $(this).parent();
//now we have a few not so great choices
//1.
var index = $("#sometable thead tr).index($th);
//2.
var index = $th.parent().children().index($th);
//3. doesn't even work, but many would assume it would, and it
doesn't!)
// because the desired element is always the last one in the set.
var index = $th.siblings().andSelf().index($th);
});
Paul Irish and I propose the following enhancement, which is rough and
we welcome any suggestions...
jQuery.fn.index = function(elem){
// legacy implementation
if ( typeof elem === 'object'){
return jQuery.inArray(
elem && elem.jquery ? elem[0] : elem
, this );
}
//return the index of the element in a new jQuery obj from selector,
or by default, amongst its own siblings.
return jQuery.inArray(this[0],
elem ? jQuery(elem) : this.parent().children() );
};
which would allow for the following.
$("#sometable th img").click(function() {
//find out index of img's parent <th> in its own <tr>
var index = $(this).parent().index();
//for sake of example, index of image in set of all images.
var imgIndex = $(this).index("img");
});
If people think this is worthwhile, we will post an enhancement
ticket. Thoughts?

Would post a ticket but the trac is down....
in the _init method
22: max: !this.options.scroll ? 10 : 150,
overrides whatever the developer has supplied for the "max" option.
something along the lines of this works.
max: !this.options.max ? (!this.options.scroll ? 10 : 150) :
this.options.max.
However I'm inclined to think the inner ternary should be moved down
to $.Autocomplete.defaults....

What is this error meant to signify? There have been a few threads
about this, but they contained nothing conclusive. The error seems to
only be thrown by the switchTab() method, but it doesn't even appear
that my tabs are initing properly - classes are applied, but the
content of all the tabs is visible. I've got tabs 1.6rc2 running
great on one site, yet on this one (it's Drupal, granted), I can't
seem to get it going. Any insight on this error and what it is
indicative of?
Descriptive exceptions are great, except when there's no documentation
of what they actually mean...

Anyone have a clever method for doing step-debugging on scripts
fetched via $.getScript() ? In firebug, if you add a "debugger;" to a
remotely fetched script, Firebug shows the variables in the watch tab,
etc, but it doesn't actually pull the script into the script window
(it shows another page, scrolled to the line number of the debugger
cal in the remote script). If you do the same ("debugger;") and
you're using IE and Visual Web Dev for debugging JS, VWD just crashes.
Obviously it's a pain to have to tweak my code to have remote scripts
loaded not-remotely just when I'm debugging the actual remote scripts,
so I was wondering if anyone else out there had dealt with this and
figured it out....
--adam
PS. there are no cross-domain issues

don't know if anyone has encountered this before, but I'm using CF8
components to return JSON to my applications, but even when i specify
"dataType:'json'" on my ajax requests in JS, ColdFusion returns
something along the lines of the following:
-----------------------------------------------------
<!DOCTYPE HTML PUBLIC "-//W3C/DTD/HTML 4.0 Transitional//EN">
{"userclassid":1.0,"unique_session_id":"19714_38786260"}
----------------------------------------------------------------------------------------
and jQuery's json parser can't parse it because of the doctype string
on the response. i've written a stupid utility function that finds
the beginning of the string and parses the json using json2.js, but
it's obviously an extra step that i'd like to get rid of. has anyone
else encountered this issue and solved it?
--adam

i've posted various takes on this problem before, but after re-
encountering it today, i must enquire again.
so i'm in a function
function hey() {
    var dc = $("div.column"); // at this point, the variable "dc" has all
these different objects that seem to represent all the available
plugins
    $("div.widget").each(function(i) {
            var dc = $("div.column"); // at this point, i get the same exact
thing for "dc" when i look in the debugger
            someCode();
            $(this).clone().load("anyURL.htm",function() {
                var dc = $("div.column"); // at this point (in IE) i do NOT get
the same selection...they are missing all the objects that i think
represent the plugins. everything called from this point starts
getting REALLY wonky...ie, can't find the plugins. in FF, i have
similar (what i assume are) scoping issues, though they start lower in
the call stack...
            });
        });
}
in other words - $ is not the same as $.
has anyone encountered anything similar? any advice? i had band-
aid'ed the issue in firefox by doing things like
var jq = $;
$(this).load(function() {
$.extend(jq);
});
but today i went to debug my app in IE and encountered the same
problem where it hadn't been occurring in FF. lo and behold though,
it's the same issue of "missing plugins..."
thanks a lot.

i've tried to get an answer to this question before, but been
unsuccessful - however, it's becoming a more general issue and i
really could use a solution if anyone can offer one.
my problem is that at different points in the call stack, the object
jQuery.fn doesn't necessarily have all the same things in it. if i
look at jQuery.fn right when $(document).ready() is called, all the
plugins i've set up are listed as available methods in firebug. i ajax
in some content, and ajax in more content inside of that content, and
pretty soon jQuery.fn has far fewer methods inside of it if i look at
it when executed in the context of some of the ajax content.
thus far i've solved the issue by duplicating jquery into another
variable and passing the cloned jquery into functions where it appears
to be "missing things" and extending the "missing" jquery with
everything in the clone. this feels bootleg as hell and is less than
reliable.
maybe i just don't understand closures or some other rudimentary
aspect, but this is beginning to get dire for me. help! please!

with jquery ui 1.0, i had a lot of trouble getting sortables to
refresh, but was able to hack it together using floris barnhoorn's
extension that added refreshSortable() and it kind of worked.
well, here we are, ui 1.5, and i can't get the sortable("refresh") to
refresh my sortable. i've done some cursory debugging (as i don't
really know how to solve the issue) and i know that the "new" item is
making it into the "items" object generated by the refresh function,
but ultimately it's not ending up sortable.
has anyone had any success (or similar failure) and could point me
towards an indication of what is going wrong, what i can look to in
order to see where it may be breaking?
--adam

i posted a bit earlier but i've synthesized the problem a bit. in the
code below, one would expect the variables mb2 and mb3 to contain the
same things as each other. however, mb3, which wraps the same element
with jQuery inside of the bound function, ends up just being an
unextended jQuery object, while mb2 has all the extended functionality
provided by any plugins on the page.
    function makeMenubar(w,wid,c) {
        var menu = $("##"+w+"Header");
        menu.append("<a class='close' id='"+w+"_close'/>");
        menu.append("<div class='menubutton' id='"+w+"_menubutton'></div>");
        var mb = $("##"+w+"_menubutton");
        $("##"+w+"_menubutton").click(function(e) {
        var mb2 = mb;
        var mb3 = $(this);
        fileMenu(w,e.clientX,e.clientY,c,m);    });
        $("##"+w+"_close").click(function() {closeWidget(wid,w);});
    }
does this make sense to anyone or ring a bell?

i'm in the midst of developing an application with many jquery
plugins, and i've just run into a bizarre problem. my app uses a lot
of ajax to populate different divs that i'm sorting using sortable.
anyhow, the issue is as follows.
on document ready, i go through each div on the page and ajax in the
content for it using .load().
$("div.widget")
    .each(function() {
        var w = this.id;
        var wid = $(this).attr("title");
        var h = $(this).attr("alt");
        $(this)
            .load(w+"/index.cfm",function(){
                var choices = {};
                $("##"+w+"_choices li").each(function(i) {
                                            var c = $(this).text();
                                            choices[i] = c;
                                        });
                makeMenubar(w,wid,choices);
                widgetInitCall(w);
            });
    });
once it arrives, i call another function to find a specific h1 in it
and add some buttons, one to close the div and one to access a menu.
    function makeMenubar(w,wid,c) {
        var menu = $("##"+w+"Header");
        menu.append("<a class='close' id='"+w+"_close'/>");
        menu.append("<div class='menubutton' id='"+w+"_menubutton'></div>");
        $("##"+w+"_menubutton").click(function(e) {var f = new
FileMenu(w,e.clientX,e.clientY,c);    });
        $("##"+w+"_close").click(function() {closeWidget(wid,w);});
    }
the problem i'm having is that if i attempt to use ANY PLUGIN AT ALL
in the anonymous functions bound to those clicks (or any functions
called by those functions), i get a "not a function" error in my
firebug console. i'm ultimately attempting to use ajaxForm() on a
form that gets ajaxed in, but in debugging it i found that even
something as simple as the following ends up erroring out.
    $("##"+w+"_menubutton").click(function(e) {
            alert($(this).outerHeight());
        });
all the plugins that i want to use are in the page and work fine if i
call them from somewhere higher up. can anyone offer any insight? i
couldn't find anything about losing access to all plugins at certain
point in the call stack. this is really throwing a kink in the middle
of my day. thanks a lot.
--adam

hi,
i am having an issue using the draggable plugin, insofar as some
options are simply not taking effect, while others are. i have created
this test page to demonstrate the issue:
http://www.ajpiano.com/ajaxtest/testme.html
the grey box in the top right corner is our boy:
$("#mydiv").draggable({
            opacity: .1,
            helper: 'clone',
            stop:function(e,ui) {alert("stopped dragging" + ui);},
            revert:true,
            grid:[50,50]
            });
});
as you'll see in the example, i can define the various functions, and
the "helper" option works, but neither the opacity, revert, or grid
options are working. if you stop execution during the stop function,
for example, you'll see that the ui object actually has those options
defined - they're just not....happening?
this is happening in both ie and ff.
thanks for any aid.
--adam