Iframe VS Includes

It is a tired old argument that frames and iframes are some how superior to server-side technologies for modular document construction. The notion that iframes are easier to code, more dependable, easier to maintain, and style is just not true. Here is a little demonstration of just some of the shortcomings with iframes. I'll just focus on the styling and maintenance issues. There is much more out there with a plethora of discussions on the bookmaking, content synchronization, scripting, and security issues associated with iframes all over the web.

This page is not pretty. It is styled to illustrate the iframe issues. I also recommend that you view it with more than one browser so you can see how iframes are browser-dependent so if your goal is a constant style across browsers, iframes will complicate your mission.

Small Inline Content

This is a test of some short length inline content. Notice when using iframe you have to "know" ahead of time what the size of the content is. Also note the page styling does not continue seamlessly. So here is some . Looks great, no? BTW some browsers like MS IE the iframe background is nottransparent, so the iframe's background will be default white!

Okay let's see it with a PHP include. So here is some short inline content. Hmm better?

Large Inline Content

The size issue with iframes is also a problem with large inserted inline content. Let's compare iframe: . And now via a PHP include: Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Ut commodo volutpat augue. Morbi hendrerit, lorem vel iaculis congue, orci est vehicula mi, scelerisque hendrerit urna leo tempus justo. Integer lacinia, dolor id lacinia pulvinar, lacus odio tempus mauris, sit amet porta eros justo id mauris. Nam dolor erat, cursus non, fringilla commodo, convallis scelerisque, massa. Duis ac ligula. Nulla aliquet. Vivamus porttitor ligula dictum elit. Ut sagittis pede non lectus. Ut interdum eleifend felis. Donec erat lectus, venenatis at, accumsan non, eleifend ac, nibh. Praesent hendrerit tempor eros. In vulputate fringilla felis.

Wow! That scrollbar really makes the iframe version seamless don't you think? Sure you can fiddle and tweak the width and height attributes but if the content is dynamic you're screwed. Also note you do not know what the user's font size will be. What if the user overrides your carefully tweaked to 14px-font-size-page with a min-size of 17px? Can you guess what will happen?

Block Content

Now for a very common application, and said "virtue" of iframe, the common menu. The claim is that iframes make document assemble easier. So let us see how they stack up?

Now iframe is an inline element so it is not valid as a direct descendant of the body so we need to wrap in a block element, so I will use the generic div. Hmm but again my styling is gone--no nice dark green block with stacked links floating to the left of this paragraph. Now that is just great!

With PHP include I get what I expect, a nice green menu. Okay I guess I ads styling within the menu fragment to assist the iframe, but how would that assist in making things simpler? Whenever you make a styling change you will have to hunt down and tweak all the fragments in these include files!

Complexity

Another false claim is that coding an iframe is simpler than server-side. Okay let's compare with PHP include which I have used in this demonstration.

<!-- IFRAME -->
<iframe src="short-inline.html" frameborder="0">
[Message when iframe is not available]
</iframe>

<!-- PHP INCLUDE -->
<?php include("short-inline.html"; ?>

PHP include does not seem too complicated at all. PHP is simple and almost universally available, if not PHP then some other server-side technology is available on all but the barest of hosting. Since you can get PHP with many free hosting services, "no-PHP" is not are real excuse. Some benefits over iframe are: