| This is the first of many "snippets" that I'm going to start publishing as I find come across them - every day there seems to be "something strange" going on with one of my web sites or another, and I have to share them or I'll explode! The latest one involves serving my banners from inside IFRAME's. I've discussed my use of IFRAME's before briefly when writing about my Diary. Background: Serving bannersBefore getting onto the problem I've been having with IFRAME's, I'll fill you in quickly on why I use them since that'll be useful info for some of you. Although I wrote my own banner system, and it's still there both on this site and in the download, my site recently joined the ASP Alliance Advertising Consortium. Member sites are hand-picked and a strict "black-ball" rule enforced - if any site disagrees with a proposed new member, they don't get in. Banners are served differently by the consortium, and are now loaded with client-side JavaScript served from the central ASP Alliance server, not mine. Using JavaScript like below allows us to serve any HTML, not just images, but as we quickly discovered, there's a catch to this. <script
language="javascript"
src="http://ads.aspalliance.com/displayad.asp?m=6&t=1">
</script> |
The catch is that the browser doesn't know what's coming from the JavaScript - it doesn't know that it'll send a 468x60 image or a 100x30 image or some HTML, and there's no way to tell it. Using a <img> tag you can, with the width and height attributes. Without a hint on how "big" the JavaScript output will be, the browser can't display any surrounding tables, so sites like mine (in one big table) don't show at all until the JavaScript gets downloaded, executed and the resulting image downloaded. This has taken up to 8 seconds at times, and that's the kind of behaviour that makes people quite rightly leave a site, never to return. Part 2: IFRAME's to the rescue...ish... | 
