The backwards incompatible change to $.fn.add() in jQuery 1.4 is bugging me.
First of all, it's breaking some old code, and second of all it bugs me because I don't get *why* it was changed to return a source-order sorted collection.
Consider this bit of code:
var newElm = elm.prevAll().add( elm.parent() ).eq(0);
In 1.3.2 and earlier `newElm == elm.prev()`, whereas as of version 1.4 `newElm == elm.parent()`.
Questions:
Could someone help me understand why this change to `.add()` was a) beneficial and b) neccessary?
Wouldn't it make sense to add a `$.fn.sort()` method (or `$.fn.order()` if you will) to perform this action more generally?
Would it be too late to revert `.add()` back to its old first-in-first-out behaviour, and save us all the trouble of patching/reworking our old code?
I just got bitten by an unexpected (for me at least) behaviour of the jQuery() function: $(), $(''), $(0), $(null) and $(undefined), all return a collection equal to $(document). ...this causes weird things to happen when one converts a String to a dom, when the string happens to be empty. Somehow I expected $('body').append( $(html) ); to be functionally equivalent to $('body').append( html ); Is that an unreasonable expectation, and if not, is it too late to fix? -- Már
It seems possible to ever so slightly optimize $.className.add(), $.className.remove(), and $.className.has() by adding an up-front check to see if the `className` parameter is a non-falsy value (not just `undefined`). This would avoid triggering costly processing such as envoking $.each loops, .splits() and functions, and even possibly document reflow (when re-assigning unchanged values to an element). One could also check for the existence of element.className before attempting to remove any classNames. It seems like a place ripe for optimization. -- Már.
Hi. If it hasn't been already considered (and rejected), I'd like to float the idea of adding support for prototypal inheritance into the jQuery core library. Something like this... jQuery.beget = function (proto, props) { var F = function () {}; F.prototype = proto; var instance = new F(); return props ? $.extend(instance, props) : instance; }; ...becomes immensely powerful - especially during plugin development when allowing users to extend/override default options options = $.beget($.myplugin.defaults, options || {}); ...and in various other common use cases - including $.fn.data() assignments, etc. I for one would love to see this feature added. -- Már
Seems like Sizzle isn't cleaning up after itself in IE. After a few round-trips, I'm seeing a lot of this in an Element that has it's `.innerHTML` edited and then posted to a server: <table width="100%" cellspacing="0" done2="4" done4="4" done5="4" done3="4" sizset="4" sizcache="4" summary=""> <tbody done2="4" done4="4" done5="4" done3="4" sizset="4" sizcache="4"> <tr class="alt" done2="4" done4="4" done5="4" done3="4" sizset="4" sizcache="4"> <td done2="4" done4="4" done5="4" done3="4" sizset="4" sizcache="4"> </td> </tr> </tbody> </table> I'm also seeing tons of `jquery1234377093764="43"` attributes all over, even in places that I'm pretty certain I haven't bound any event- handlers or data to (not via my code, nor via any 3rd party plugins). I wonder if there are any plans for making Sizzle less "obtrusive" in this regard... (See ticket: http://dev.jquery.com/ticket/4282) -- Már Örlygsson
I was bitten by my assumption that $.fn.not was simply an inversed $.fn.filter() ... ...which it isn't, as it doesn't accept functions as an argument. Is there a good reason (API-wise) for this difference? -- Már
I just created a ticket (http://dev.jquery.com/ticket/4174) with demo/ test-cases for both versions of jQuery... --------------------------------------- The following code produces quite different results in jQuery 1.2.6 and 1.3.1 ... var protoElm = $('#proto b'); protoElm .bind('click', function(e){ alert("I'm a click event!"); }); $('p') .append( protoElm ) .prepend( protoElm ); Results in jQuery 1.2.6: All paragraphs have a <b> element appended and prepended Clicking all <b>s triggers an alert! Results in jQuery 1.3.1: The prototype <b> disappears Not all paragraphs have a <b> element appended and prepended. Only clicking the first <b> triggers an alert!
`$("#foo").remove()` removes all event handlers and stored data. But, sometimes I'd like to temporarily remove an element from the DOM for later reinjection, in which case the event and data removal becomes a nuisance. Is there a way to do that in jQuery - aside from writing your own `.removeTemp()` plugin? `$("#foo").remove(true)` `$("#foo").remove(selector, true)` feels like a natural way to express this. any thoughts? -- Már Örlygsson
I've found that in IE 6 & 7, jQuery 1.3.1 seems to return incorrect CSS opacity values for elements that have `filter: alpha(opacity=N);` applied in a stylesheet. However, elements with their opacity level set with a `style=""` attribute, return the correct number. Additionally elements with opacity set to `0` seem to return `1` in IE 6 & 7... Here's a test case: http://mar.eplica.is/ie-opacity-bug-demo.html And another test using my patched version of jQuery 1.3.1: http://mar.eplica.is/ie-opacity-fixed.html Direct link to the patch: http://mar.eplica.is/ie-opacity-fix.diff I don't know, if this bug has been fixed or rejected. My brief search came up empty. -- Már Örlygsson
`$('<p />').parent()` returns the <div> wrapper for the innerHTML injection when creating the paragraph element. This makes it impossible to distinguish between a newly created element and an element that is intentionally wrapped in a <div>. Smells like a bug. Can this be fixed without breaking lots of other functionality? possible fix would be to add something like: while (div.lastChild) { div.removeChild(div.lastChild); } *after* the line elem = jQuery.makeArray( div.childNodes ); within `$.clean()`. -- Már Örlygsson