As you can probably guess, I-Frames can and do serve ads, and while to the end user they look like regular graphics on a web page, the technology behind I-Frames makes them much more attractive to advertisers than a regular banner. Essentially an I-Frame appears as an image on the page. The host browser reserves space for the I-Frame just as it would for a banner, a skyscraper, a half-page or full-page ad, or another format, and while the host page is loading it requests the I-Frame contents from another web page, an ad server, or anywhere else on the Internet.
I-Frames can contain text, links, or any other HTML or rich media (Flash, etc.) element. They’re also scrollable (like their predecessors), so you can scroll through a document—or an entire web page—inside an I-Frame without scrolling the original page. But the best features of I-Frames are that (1) tracking displays and click-throughs is really easy, and (2) their technology allows advertisers to change their creative mid-campaign without sending new “tags.”
As with any new technology, there are some problems with I-Frames, one being fairly common—they don’t seem to work properly on Macintosh computers. There are also several reports of I-Frames’ not working properly with older browser versions, but an animated GIF banner tag, now appears between the starting and ending I-Frame tags, which ensures that compatible browsers see the I-Frame and incompatible ones see a GIF. If nothing else, I-Frames are more robust than Shockwave tags, which claim to be capable of such substitution but in reality very rarely work. Another turn-off is that most email systems don’t know what to do with an I-Frame. So while running a website campaign using I-Frames is relatively headache-free, an email campaign would be very problematic. Naturally, as HTML email becomes the norm and plain text the exception, email readers will be forced to deal with all HTML elements, including I-Frames.