IE 8 RC1 hopeless?

[jscheuer1]

I've been working on a modular jQuery marquee for text and/or images. Just about everything went along fine until I decided to test it in IE 8 RC1. I wanted to make sure that images were loaded before trying to determine the length of a marquee that contained one or more images. I devised a simple and fairly standard construct (which works in all other modern browsers, including IE 7):

 function finaltouch(i){
   var ims = m[i].find('img'), c = 0; if(ims[0]){
   ims.each(function(){
   if(this.complete) c++;
   });
   if(c < ims.length){
   setTimeout(function(){finaltouch(i);}, 300);
   return;
   }
   }
   w[i] = m[i].width(); t[i] = Math.floor((m[i].parent().height() - m[i].height()) / 2);
   m[i].css('top', t[i]).next('div').css({top: t[i], left: w[i]}).parent().css('visibility', 'visible');
   while(m[i].parent().width() > w[i] - mq[i].inc)
    m[i].parent().css('width', (isNaN(cw[i][0])? w[i] - mq[i].inc : --cw[i][0] + cw[i][1]));
   runit(i);
 }

The construct is highlighted, and the line that I think IE 8 is barfing on is in red. In that line, IE 8 just doesn't seem to grasp what i is.

[codeexploiter]

Hi john is there any link to view this issue?

[jscheuer1]

Well, right now I'm using the emulate IE 7 meta tag to deal with the problem, here:

http://home.comcast.net/~jscheuer1/side/jq_marquee/

You can see the exact same page without the meta tag misbehaving (at least in my IE 8), here:

http://home.comcast.net/~jscheuer1/s.../index_bad.htm

I did a test, and it appears that this is some wierd interplay between the script and the browser, as IE 8 can handle this:

function test(i){
i++;
if (i < 10){
alert(i);
setTimeout(function(){test(i);}, 300);
}
}
test(0);

just fine. But I also found that putting an alert in the other code likewise 'resolved' the problem.

Another screwy thing about IE 8, this:

<div style="position:relative;overflow:hidden;border: 2px solid black;height:2em;">
<div style="position:absolute;top:0;left:0;width:2000px;border: 2px solid red;">
Hi
</div>
</div>

causes an empty horizontal scroll bar at the bottom of the page. That one's easier to fix, just wrap it in another div with overflow:hidden. But the first wrapper should make that unnecessary, and does so in all other modern browsers. If it is a matter of IE 8 following a stricter standard, then I would think that the additional wrapper shouldn't fix it, and that the scroll bar shouldn't be empty.

[jscheuer1]

After more testing I've found that IE 8 just seems to have intermittent problems with that construct (it also does this elsewhere in the script if it runs long enough), forgetting initialized values, sometimes of the function name or of the variable argument passed with it. Even with IE 7 emulation, it happened, though much less often. I thought this might be due to some interplay with jQuery though, as I've not been able to get it to barf on this in a very simple example. I'm also thinking that naming the passing function which can remain anonymous may be a factor, but it is valid and supported by all other modern browsers. I did port this to a script using only ordinary javascript, and I'm not sure if IE 8 barfed on this there. It did barf on the script assigned styles though, and in a different way than with overflow (though perhaps related) like I mentioned before and that I haven't been able to definitively track down yet, causing all but the first marquee to hop up and down rapidly. Once again IE 7 emulation or any other modern browser and this was a non-issue.

I'm quite frustrated at all of this but will test more when I have the time. In the mean time I am tending toward a diagnosis of IE 8 (the RC1 version of it anyway) as hopeless.

[Twey]

Well, it is still in early development. Still, that's a pretty serious bug to let in at any stage.

[jscheuer1]

Well, it is still in early development.

Knowing your general attitude to most things MS, that's pretty charitable. I see where you are coming from. But - MS announced an anticipated official roll-out earlier than now, and have been pseudo promoting the various beta and this RC version as 'official', not going so far as to state as much, but by virtue of how they are presented for download, misleading many, many people. I've even just recently heard that Vista users that install 8 are finding it very hard to find a rollback installer for 7.

I was sick and tired of hearing about 8, so I devised a plan to create a testing environment. Things didn't work out exactly as I had planned, but at least my primary machine was spared and I have a testing environment on an old LAN node over which I have complete control.

I put up with all this crap when 7 came out, but this time I think MS is trying to have it both ways even more than usual - leading people to believe that 8 is a fait accompli, while at the same time not supplying a stable official release, all the while dicking around with development that should have been conducted in private, only because they feel threatened by other superior existing products.

[jscheuer1]

I'm still exasperated with 8, but I have found a workable solution, and it's kind of funny how it happened. I was playing around with my pure javascript version, and noticed that 8 had no problem with the aforementioned construct as used in it, just that jumpiness business, which was absent from the jQuery version. So I decided to port my port back to jQuery one line at a time to see where the jumpiness was coming from, it was here:

tag.innerHTML = '';

This is used after the innerHTML is saved, trimmed of leading and trailing whitespace and prepended with a single nbsp entity, and before the markup for the marquee is built up inside the existing div tag, to clear that tag out. In jQuery, this is done:

$(tag).html('');

and I have no idea precisely what code they use for that. But when I switched to that, the jumpiness went away. I then undid all the other modifications, and it was still good. So I figured, how about:

while(tag.lastChild) tag.removeChild(tag.lastChild);

instead? That worked fine, so I now have a completely non jQuery version that works in all modern browsers, including IE 8 RC1 in strict mode.

I've learned a few things here, one about the overflow issue in IE 8, also that the coding style I was using with jQuery was a bit sloppy even though it worked except in IE 8*. And that IE 8 does something differently than all other modern browsers when you set an element's innerHTML to an empty string, I'm not sure what though or how that could result in the jumpiness I observed.

I can now probably port back to jQuery if I like. But without all that extra code, the plain javascript version is leaner and faster in totality, if a bit longer than the version that uses jQuery.


*I think that jQuery to a degree encourages a style of coding that is sloppy because of its innate nature of turning almost everything into an array while co-opting the this keyword. But hopefully I've learned my lesson on that score. To get around that, code for jQuery (if it is at all complex) should probably be at least mapped out (outlined) first with function groups that would work with ordinary javascript, and then be spiced up with jQuery's more powerful and succinct methods.

[Twey]

It does use innerHTML, but it does an awful lot more, too. It's not possible to tell by looking at it what triggers the correct behaviour.

Nobody knows what will happen when you use innerHTML — it's non-standard, as bad as using document.all or <layer> in your HTML.

So I figured, how about:

while(tag.lastChild) tag.removeChild(tag.lastChild);

That should have been your first resort, not your last. The idiom goes:

while (tag.hasChildNodes())
  tag.removeChild(tag.firstChild);

*I think that jQuery to a degree encourages a style of coding that is sloppy because of its innate nature of turning almost everything into an array while co-opting the this keyword. But hopefully I've learned my lesson on that score. To get around that, code for jQuery (if it is at all complex) should probably be at least mapped out (outlined) first with function groups that would work with ordinary javascript, and then be spiced up with jQuery's more powerful and succinct methods.

Why do you consider that sloppy? I think the repeated uses of innerHTML without any fallback are far sloppier. The use of the context argument to pass values is really perfectly acceptable — it's just another argument, after all.

[jscheuer1]

I have no last resort. It's like, when you lose your keys (to your house or car, for example), you always find them in the last place that you look.

As for the other issue, why do I consider what sloppy? Have you written much code for jQuery? In any case, I may not have been clear about that, consider:

$('.marquee').each(function(i){
do something(s) here one at a time with each element that has a class name of marquee,
while you are at it, the index of that element will be i, and the element
itself will be this, extensible as another array object with one member but many
properties by doing $(this).
});

Now the this keyword cannot be easily used to refer to an object other than the element, and i is reserved for the index of that element in an array, so you will be tempted to use it (i) to differentiate processes which can be better done with a constructor function or object of your own devising.


* javascript:alert($(document).html)

outputs:

function (E) {
    return E === g ? this[0] ? this[0].innerHTML.replace(/ jQuery\d+="(?:\d+|null)"/g, "") : null : this.empty().append(E);
}

[Twey]

Now the this keyword cannot be easily used to refer to an object other than the element

It can't anyway, inside a nested function. It's one of the flaws of JS' OO model, but in this case it's that or nothing (or, more likely, window). There's an idiom that goes jQuery('.marquee').each((function(that) { return function(element) { /* ... do stuff ... */ }; })(this)); and refer to the old this as that (or self; personally I like to use me). You don't have to call the element i: you can call it element, mother, or piggywinkle, it doesn't care.

Note that this[0].innerHTML.replace won't always be defined; on some browsers innerHTML isn't a string, and requires a .toString() before using any string methods.