Using iFrames in xHTML 1.0 Strict

Just kidding… you can’t. But it’s a good title for a blog post since if you run into the problem that I ran into, you probably searched for that. The reality is that iFrames are a bad idea, and have been for years. The harsher reality is that they are not allowed at all in xHTML 1.0 Strict, meaning that either a browser will not even display it (which is probably the better option) or it is displayed but causes your code to not validate. Usually this never comes up, since we usually just assume that frames are bad and to avoid them.

But what about when you need to upload some images and you want to do it without updating the page? Ajax does not allow for file uploads, so that is not an option. A good example of this is a Wordpress interface when you are creating a new article. In order to allow someone to upload an image for placement in their post, there is an iFrame there to accomodate that. At least in my installation, I wouldn’t be surprised if they have upgraded that part. Either way, I want our editorial staff to be able to upload images when they are composing articles without having to refresh the page (and potentially destroy their edits). An iFrame is not an option since I am taking great care to make sure that this application is XHTML 1.0 strict, and also compliant in the Big Four browsers.

Enter the object element, whose sole purpose is to pull in external things and display them. Think of a flash presentation that is rendered in an object element with the help of a plugin. Quicktime movies displayed on a webpage use an object element and also a quicktime plugin. It turns out that you can use the object element as an iFrame, which will be xHTML 1.0 compliant and also (in my opinion) much more versatile and reliable than an iFrame. Let’s be clear, it’s not perfect, but it’s a good option to the iframe. I could also see some interesting “widgets” being developed that take advantage of this behavior.

Actually, to catch myself in a lie real quick, I didn’t test this yet in IE6. That’s partially because I haven’t gotten around to it but also because I just don’t care. As time goes on it will be going away, and it’s important to look to the future when developing and application, and not to the past (too much). So really I can only confidently say that this works in IE7, Firefox, and Safari. There, I said it.

So here is the code. For the most part, it’s just like using an iFrame except that the tag is different. Otherwise nearly all the behaviors are the same as an iFrame with the additional bonus of being able to style it a but more in all browsers. Not to mention that it validates. Simply place this code in your HTML document where you would normally place your iFrame:

And that is it. As you can see, the data attribute replaces the iFrame’s src attribute. Since in this case I am only loading html pages into the object, I specify that the type is text/html. The only thing to note is that your browser will probably try to cache the “frame”, or the content that was loaded into the object. This can cause some problems depending on your application, and at the very least is annoying during development. In order to suppress this behavior I send the following headers with the page that is loaded into the object (/path/to/html_file.php):

Expires=0
Pragma=no-cache
Cache-Control=no-cache, no-store, must-revalidate

I suppose in this example you would do this with PHP before the output of the /path/to/html_file.php is sent to the browser. In my case I am working with Rails, so I specify these headers in the controller for this page. Basically the same thing. You’ll have to figure that one out for your application, but if that solves a headache with trying to figure out why changes are reflected during development.

And that is my little find on object elements. While I can’t stress enough that this isn’t much better than frames, and should always be a last resort, it does work. And it works well across different browsers. Search engines will not follow through, like frames, so this should not be used on public pages or pages where you want good SEO form. I’m using it in a protected administration area that the search bots won’t have access to. And that is my disclaimer. Otherwise, have fun.

This entry was posted on Monday, November 26th, 2007 at 8:15 pm and is filed under Website Design, Application Development. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

↑ Back to Top

Brian Getting is the Online Director at Practical eCommerce, specializing in website design and application development.