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...
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)
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
I may soon need to track mouse movements in various multiple containers in a webapp. I was wondering if using $.live would be impractical in this scenario since $.live binds to document and may degrade performance if you need to track numerous mousemove events but only inside a limited area. would it not be much better to explicitly specify containers in this case to prevent significant performance degradation involved with doing so much filtering regardless of cursor position within the document? is there any way to explicitly define parent containers in $.live rather than using the default of document? Leon
Hehey! just wondering if you guys considered pulling any of these into the core (in my order of want-ness): - better handling of text nodes (http://plugins.learningjquery.com/ textchildren/) - right click event (i know this is 2-5 lines of filtering code, would be nice to have in the core) - wheel events (http://blog.threedubmedia.com/2008/08/ eventspecialwheel.html) - css class animations (http://plugins.jquery.com/project/classAnim) - advanced key events (http://plugins.jquery.com/project/hotkeys) - drag/drop events (maybe in UI atm?) - color animation/fading - native JSON parsing/stringification (http://json.org/json2.js) (maybe the mozilla gods will land native support for this in 3.1) i think most of these are generic enough to make them decent candidates. also, will 1.3 utilize native getElementsByClassName (when available)? regards, Leon