i have the following javascript below after i finish an ajax query
all of my images have name="pic"
<script type="text/javascript">
function done() {
var e = document.getElementsByName("pic");
alert(e.length);
for (var i = 0; i < e.length; i++) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
}
my goal is to apply an image border around using this library:
http://www.netzgesta.de/instant/
the problem is that for some reason this works but it only seem to apply to every other picture instead of every one. any clue why the code above would skip every other element??
EDIT: I added an alert in the loop and it does correctly go 0, 1,2,3,4,5,6 . .
for (var i = 0; i < e.length; i++)
{
alert(i);
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
it only seem to apply to every other picture instead of every one
That's a classic sign of destructive iteration.
Consider what happens if, as I'm guessing, the function cvi_instant.add
replaces the element named pic
with some other element or elements.
getElementsByName
returns a ‘live’ NodeList: it is kept up to date every time you make a change to the DOM. So if it had five elements before, after your call to cvi_instant.add
it now contains only four: the first node is gone and nodes 1–4 have moved down to positions 0–3.
Now you go around the loop again. i++
, so we're looking at element 1. But element 1 is now what was originally element 2! We skipped the original element 1, and we will continue skipping every other element until we reach the end of the (now half as long) list.
Altering a list at the same time as iterating it causes this kind of problem. If the process inside the iteration actually adds elements to the list you can even get an infinite loop!
The quick fix is to iterate the loop backwards. Now you do the last element first, leaving all the other elements in their original positions and causing no skipping:
var e= document.getElementsByName("pic");
for (var i= e.length; i-->0;) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
Another simple solution if you know you're always going to be removing the element from the list on each call is:
var e= document.getElementsByName("pic");
while (e.length>0) {
cvi_instant.add(e[0], { shadow: 75, shade: 10 });
}
The most general solution is needed when your loop body can do anything to the list, such as inserting new elements named pic
at the start of the document or removing other elements from the middle. It is slightly slower but always safe to make a static copy of the list to work from:
function Array_fromList(l) {
var a= [];
for (var i= 0; i<l.length; i++)
a.push(l[i]);
return a;
}
var e= Array_fromList(document.getElementsByName("pic"));
for (var i= 0; i<e.length; i++) {
cvi_instant.add(e[i], { shadow: 75, shade: 10 });
}
My guess is that cvi_instant.add() is doing some incrementing or iteration on the values passed to it. Try doing this instead - it's easier, and I believe it will fix your problem:
function done() {
var e = document.getElementsByName('pic');
for (pic in e) { cvs_instant.add(pic, { shadow: 75, shade: 10 }); }
}
Hi I came across the same problem.
My script was skipping every other
element. I finally solved it by simply
changing the variable name from i to
k in my loop. My guess is therefor
that the variable i is used by
getElementsByTagName internally to
keep track of where it is in the
live nodelist and is leaking out
to the programmers interface somehow.
So its a bug! :-)
-- EDIT:
All of what I claim below appears to be totally wrong. I leave this here as a point for anyone who thought the same :) I tested in FF3. I would love to claim that I saw this behaviour once, in IE, but maybe it was many years ago (come to think of it, it was probably 7 years ago). My memory is probably bad :)
-- OLD:
To slightly expand on my wild guess, if it turns out to be accurate:
From memory, if you don't declare a variable ('var ...') it'll use one from somewhere else.
Thus, without testing, this code:
for(var k = 0; k < 2; k++){
f();
alert("k: " + k);
}
function f () {
k++;
}
Should show the same behaviour. I think TML's solution is quite nice, from a 'defensive coding' point of view, it my analysis turns out to be correct.