that is...the results of multiple promises are passed to the done/fail/progress callbacks via .apply(this, resolvedValues). Most other .all() implementations (Q.all, when.all, RSVP.all) opt to do this via .call(this, resolvedValues), resuting in an single resolvedValues argument passed to the callback rather than as separate arguments for each item.
i'm writing a library where i'm trying to hook into any available promise/deferred libs and i cannot find a way to make $.when behave like the other libs. is there a way to force a .then() chained to a $.when() invoke the callbacks via .call() rather than .apply()?
what's the point of the [type=*] pseudo-class selectors if on every doc page the recommendation is to prefix it with "input" for speed.
of course it's best to do this, but as long as we're making shorthands why not opt to make the pseudo selectors map directly to the fast versions and remove the disclaimer everywhere. make :text == input[type=text].
how often do people need a shortcut to explicitly [type=text] or [type=checkbox] without them being inputs? my conservative guess is "never". if you need something that rare, then don't use the pseudo-selector.
the way these selectors are done now is neither here nor there. the chances of breaking existing stuff out there seems pretty slim to me. might be good for 1.7.
right now $(document).live() seems to do nothing. it should maybe just map to .bind() instead.
it's probably an issue with .live() requiring an explicit selector for filtering, but i think this is a fair exception. maybe both - "document" and "window", since they cannot be CSS-selected. minor, i know, but eh.
edit: i remember there was some talk about making .ready() live as well. could be a related solution/discussion.
animate() speeds such as "slow" and "fast" which translate to durations make no sense for varying computed animation distances. for example, animating "slow" will be lightning fast if you animate to a 2000px window width but will crawl within a 200px window width as demonstrated here:
the experience changes vastly for fluid containers and window widths since animate durations are fixated rather than the actual speeds (for the sake of setting a single tick timer i assume)
i propose adding a signature to $.animate which takes a plain object instead of a duration argument indicating how many units/sec should be changed for each property. this would require setting independent timers for each of them, (perhaps optimizing and grouping some). so you can do something like
maybe with a special case like "all" so they dont need to be itemized. this will somewhat complicate synchronization, since every timer may end up with different durations, but for now it doesn't seem too difficult to just keep a single animation-complete callback that fires after last timer expires and in the future maybe provide property-specific completion callbacks?
another issue might be performance, and this should be noted for the additional signature.
the flexibility afforded by this is pretty significant especially for interfaces which adapt for eg. mobile device resolutions, fluid window sizes.
i always thought it would be useful to dispatch an event without first creating it with $.event, since jQ already does this for you. on more than one occasion i found myself wishing to trigger a right click, or trigger a specific key's keydown/press/up.
it would be pretty simple to add a signature to .click()-and-friends that would work like:
.click({which: 2}) // right click simulate
.keyup({which: 53}) // '5' simulate
.trigger("click", {which: 2}) // trigger version
internally just check which signature is being used and do a $.extend(event, params) on the internally-created events before firing them off.
very easy to implement, no side-effects that i can see...
a plugin i made broke when upgrading to 1.4.4 from 1.4.2. i'm getting different behavior for focusin, focusout, blur and focus events comparing 1.4.2 vs 1.4.3+. the problem i'm running into is that after attaching "live" focusin and focusout handlers, then triggering focus() or manually focusing different text fields sequentially, focusout never triggers to coincide with blur in 1.4.3+, only focusin. 1.4.2, however works as i would expect. is this a bug, a feature, intentional behavior? it seems if the recommendation is to use focusout and focusin as replacements for blur and focus, they should trigger the same way (except for bubbling)
i'm not sure if this is a bug or i'm missing something. it seems the following should all do the same thing (select the entire first column of cells (td and th) in the table):
$('table').find('tr > *:eq(0)');
$('table').find('tr').find('>:eq(0)');
$('table').find('tr > *:nth-child(1)');
however, the first one selects the first cell in the first row only...essentially "tr:eq(0) > *:eq(0)", but the second and third work as expected.
from the comments in the :eq() docs, Karl mentions that :eq only matches a single element in the set, but it selects multiple elements in the second method.
EDIT: my actual code has to use $(this).closest('table') since it is inside a handler, so i have to use find() rather than eg: $('table tr > *:eq(0)')
was just browsing the source and noticed that there are a lot of places where there is a space-separated list of stuff in a string (sometimes multiple stings concatenated) followed by a .split().
in the places i saw it used, it's done just on init, so speed really isnt a factor. but why not just have an array?
the only benefit i see is character count in the source and one string rather than numerous. on the other hand if optimized by a compiler identical strings can be merged into a single reference.
i was thinking, instead of having a bunch of isFoo() functions, except maybe isPlainObject(), it would be useful to integrate and expose something like this for detecting object types:
syntactically it would get a bit more verbose for reuse, eg jQuery.typeOf([]) == "Array", but it can be abstracted away by isArray() as is currently if it needs to be used in many places.
however, $.typeOf() might provide a good foundation and replacement for isFunction isArray, etc...
in the current nightly usage count: 66x typeOf 35x isFunction 13x isArray 2x isBool
i have not benchmarked it at all, might be slower? thoughts? Leon
...wonder if this has to do with the recent internal reworking of the event system, but the following code no longer works for me in the nightly, while it does work in v1.4.1
is this attr() magic at work?....cause $("div").attr("selected","selected") does work.
the primary purpose of my needing to do it is for cloning, making .val() not a viable alternative cause cloneNode doesn't copy over the selectedIndex property. (the testcase is in the original thread)
.clone(true) does not seem to copy which option was selected if the "selected" attribute is not set (like when a user just chooses an option with the mouse)?
ran into the issue of originalTarget not being set inside the passed event to a keydown handler in IE8 (maybe other IEs). i'm not sure how much normalizing is supposed to be done in jQ for events, so i'm unsure if this is by design or just missed?
for now resorting to using the following: which works in FF3 and IE8
i'm not sure if this is by design or not, but while both of the following lines fire the bound handlers, they fail to actually focus the element itself.
$("#a").trigger('focusin'); $("#a").focusin();
i'm sure it's a pretty easy fix, but for the time being i have to resort to using focus() to trigger the focusin handlers + element focusing.
I know that functionally the following two are equivalent: $("table .qty").live("click", function(e){ alert("hello"); }); $tbls = $("table"); $(".qty", $tbls).live("click", function(e){ alert("hello"); }); what i'd like to find out is if the $live delegation works the same in both cases. From thinking about it, the second case would delegate less efficiently, because there is no full selector provided. the problem is that i have a function like this: function tblCalcs($tbls) { $(".qty", $tbls).live("click", function(e){ // calculation algorithms }); } to which i pass a predefined set tables where i need calculations done. i'm not sure if $.live would resort to assigning handlers to each table separately in this case and filter the ".qty" selector. would it make more sense to just always use option A? thanks, Leon
.val() now returns undefined if <option> elements contain a "value" attribute, otherwise val() returns text() of the :selected option. both actually seem incorrect to me but only the first behavior seems like a blocker regress. i first noticed that it was strange that the "single select" example for val() contains no "value" attributes, and instead returns text() if they are not present. http://docs.jquery.com/Attributes/val i just ran into this during my webapp port. testcase: http://www.thermosoft.com/test/select-val-bug.php Leon
i've been using chains like this all over my webapp: $(this).parents("li:eq(0)") it seems that closest is a direct replacement for this and a functional equiv of $(this).closest("li"). also, is there anything like nextest() that works outside the bounds of the parent container? for example: <span> <b id="foo">bar</b> </span> <span> <b>Hello!</b> </span> $("#foo").nextest("b") would return the second <b> node in the tree following the current element, but not a sibling. right now i'm needing to create funky ways to do this, unless i'm missing something. right now i'm forced to do: var $e = $("#foo"); var i = $("b").index($e); var finally = $("b:eq(" + (i+1) + ")"); ..also consider than in real life $e is not retrieved by id but is "this" inside a function and often inside of a .each loop. thanks in advance, Leon