A major problem with your technique is that the original elements are
simply no longer part of the document.
For example:
var someElems = $("div");
// length == 10
var removed = $("div.foo").remove();
// length == 5
someElems.index( removed )
// -1 (the elements you just removed aren't found!)
I did some performance testing with the following code, and found it
to be much slower than the cloneNode method, but still often twice as
fast as the current method.
jQuery.fn.removeAll = function() {
this.each(function() {
var nextSibling = this.nextSibling;
I found the culprit:
switchStylesheet($('#detailsNavigation').attr('css'));
where, in this case, the css attribute is empty.
The bug is on my side, sorry!
A.
On Tue, Dec 15, 2009 at 12:18 AM, John Resig wrote:
> Do you have any example code that triggers this error? That would
> certainly help
Do you have any example code that triggers this error? That would
certainly help to diagnose the problem. It looks like you're trying to
get a computed CSS value but are passing in an undefined name - why
that's happening would be good to know.
--John
On Mon, Dec 14, 2009 at 6:03 PM, pixeline
Hello,
I'm trying out 1.4a1 on my application.
Something breaks from 1.3.2 and firebug returns this error message:
name is undefined
jquery-1.4a1.js
Line 4047
which line is:
name = name.replace( rupper, "-$1" ).toLowerCase();
Can you help me see if this is due to an i
Hello -
This is done not for a technical reason but due to the fact that
submit buttons are only sent to the server if they're clicked by the
user. I highly recommend the form plugin for handling this case as
it'll bind a click handler and watch to see which submit button is
clicked and serialize
Hi everyone
I've been testing some old sites to start using some jQuery .post
goodness and I came across an oddity
I decided to serialize() my form data so I don't have to specify the
exact data I want posted on loads of different pages.
However I notice the value of any submit buttons isn't seri
jQuery UI does a similar thing (overriding .remove() to generate a
.trigger("remove") event). Would something like that work for your
needs?
--John
On Mon, Dec 14, 2009 at 11:43 AM, Justin Meyer wrote:
> Is there a 'teardown' for plugins that can get triggered automatically
> (similar to that
The case is precisely it: We do it that way because we need to support
array-like objects as well. (The docs are written in that particular
manner because saying .inArray(ArrayLikeObject) would probably just
confuse the issue.)
If the difference is between doing an extra .call() (which is slower
t
Why is it done this way:
inArray: function( elem, array ) {
if ( array.indexOf ) {
return array.indexOf( elem );
}
for ( var i = 0, length = array.length; i < length; i++ ) {
if ( array[ i ] ===
As is the case with any API change in a major jQuery release (1.x
releases are major jQuery releases) we always document the results and
we always provide a backwards compatibility plugin. This has suited us
very well in the past and should continue to serve us well for the 1.4
release.
--John
Is there a 'teardown' for plugins that can get triggered automatically
(similar to that for events)?
It's extremely common, and a source of bugs when I see:
$.fn.mySuperPlugin = function(){
...code ...
$(document).click(function(e) { ...code... });
...code...
}
Yes, they should be doing adding/r
And http://github.com/jquery/jquery/blob/master/src/core.js#L647
On Dec 14, 4:57 pm, Brandon Aaron wrote:
> http://github.com/jquery/jquery/blob/master/src/core.js#L49http://github.com/jquery/jquery/blob/master/src/core.js#L571
>
> --
> Brandon Aaron
>
> On Mon, Dec 14, 2009 at 4:16 AM, caii wro
http://github.com/jquery/jquery/blob/master/src/core.js#L49
http://github.com/jquery/jquery/blob/master/src/core.js#L571
--
Brandon Aaron
On Mon, Dec 14, 2009 at 4:16 AM, caii wrote:
> Array.prototype.indexOf?
> where it in JQUERY?
>
> On Dec 14, 6:13 pm, Robert Katić wrote:
>> Already fixed. I
I use .attr() to get the href attribute value, too. If you
use .getAttribute(), IE6 and IE7 require a second argument to really,
truly get the attribute: somelink.getAttribute('href', 2)
--Karl
Karl Swedberg
www.englishrules.com
www.learningjquery.com
On Dec 14, 2009, at 10:0
If this is going to stick, what about a fallback flag?
This way if it breaks code/plugins and the page developer doesnt have
enought knowledge to fix the broken code, he can always set the flag
to switch the behaviour.
Then in a MANJOR release (2.x) there would be no fallback.
IMHO, any API/beha
On Dec 13, 11:27 pm, Matt wrote:
I'm not going to jump into these murky waters, but I want to follow up
on this bit:
> As it is now, I always recommend that attr() be avoided in code, and
> if someone uses it in code I am looking at, I tell them to remove it.
> It's too fragile and the logic tha
Array.prototype.indexOf?
where it in JQUERY?
On Dec 14, 6:13 pm, Robert Katić wrote:
> Already fixed. If Array.prototype.indexOf exists, then it is always
> used.
>
> On Dec 14, 10:38 am, helianthus wrote:
>
> > This occurs when using jQuery.fn.index, which utilizes jQuery.inArray.
> > Since the
it's no about Array.prototype.indexOf. where ie it?
On Dec 14, 5:38 pm, helianthus wrote:
> This occurs when using jQuery.fn.index, which utilizes jQuery.inArray.
> Since the jQuery object does not have an indexOf method, it falls back
> to the for loop approach, while Array.prototype.indexOf cou
Already fixed. If Array.prototype.indexOf exists, then it is always
used.
On Dec 14, 10:38 am, helianthus wrote:
> This occurs when using jQuery.fn.index, which utilizes jQuery.inArray.
> Since the jQuery object does not have an indexOf method, it falls back
> to the for loop approach, while Arra
This occurs when using jQuery.fn.index, which utilizes jQuery.inArray.
Since the jQuery object does not have an indexOf method, it falls back
to the for loop approach, while Array.prototype.indexOf could have
been used.
--
You received this message because you are subscribed to the Google Groups
> I disagree. Being able to set all the (useful) properties of a DOM
> element via a single object structure can be very useful - and I see
> no reason not to overload the existing .attr() behavior if it already
> covers most of the functionality well and if there are no conflicts. I
> especially t
22 matches
Mail list logo
