Good Reasons Why Not to Use Iframes in Page Content

Good Reasons why not to use Iframes in page content

Source: http://www.rwblackburn.com/2012/07/iframe-evil/

So it seems that every job I work on, the same topic comes up. Someone, at some point will say, “just use an iFrame for that”. Then I need to go down the old tired road as to why that would not be a good idea.

Well, this article is going to be a bit utilitarian for me. I hope to put down in a single place all the reasons iFrames are not a cure-all solutions so that I can save myself some time in the future and just point people to this URL. As such I may update this post on occasion as I refine these points. Feel free to use this post for that same purpose if you like, and please post any suggestions or points I have missed to my twitter account (@rwbDev ), I’ll be sure to credit you if I add the point to this article.

Now, let me be clear. iFrames do have a valid purpose. I have actually used iFrames many times myself with great success. The problem is that people tend to want to use them to get around poor architecture, or as a simply fix to a problem. In my experience this usually just trades a small problem for a much bigger problem down the road, and more often than not it’s an unnecessary trade off. I will cover both these points below.

Bad For SEO. This is one of the most prevalent reasons you will find for avoiding iFrames. Some search engines may have difficulties with the pages referenced within iFrames. How much this affects a site’s or page’s search ranking is not fully know. However most experts I have talked to agree that it definitely has some impact. Check out this interesting form post on the tropic. For detail on how SEO works, and impacts of design decisions like this I would suggest checking out seomoz.org . This of course is not an issue if SEO is not a concern for your page or app. For example an application which requires a login (all the pages behind the login are not accessible to the search engines anyhow).
* Note (added June 6th, 2013): Recent tests have shown that search engines may in fact follow links within an iFrame. This means the SEO impact of an iFrame is much less then it has been in the past. It is still unclear that there is no impact, and different search engines may behave differently in this regards.

Linking/Bookmarks. Unless you introduce extra JavaScript, the user will not be able to obtain a link directly to content within the iFrame. This includes links someone might email a friend, bookmarks, or pages that come up in a search engine result. Imagine your user goes to your page, and some content is in an iFrame. They click a link in the iFramed content. This content will stay within the iFrame as expected. Now your users finds some content they have navigated to within the iFrame and would like to send it to a friend. But copying the URL in their browser will not work, that would just send the friend to the initial page, with the original content displayed in the iFrame. There are scripts out there which can get around this. I have implemented these myself a few times (in situations where I had no choice). However these often introduce some of their own issues and often have cross-browser compatibility problems. Often it is down right buggy too. Again, depending on your site or your application’s needs, this may not be an issue, but this is a big issue for most sites.

Difficulty with Debugging. This is one which people often overlooked. If you have a robust application with complex jQuery, Ajax, and other cool stuff happening all over the page – iFrames can make debugging a problem much more difficult. Is the error happening in the outer page, or the page within the frame? Browser developer tools can help with this, but even those tools don’t always make it clear where the issue is when you are dealing with an iFrame. You would be surprised how often a bug can be replicated when a page is within an iFrame, but works just fine when loaded outside the iFrame. This is an issue for any site. But especially for sites that use iFrames extensively. The more moving parts there are to a system, the harder it is to diagnose a problem.

No real performance gains. Once in awhile I will find someone who wants to use an iFrame because they feel it will increase their site’s performance. They usually feel this way because it will avoid having to reload the site’s header/footer/menu whenever the site paginates. More often than not, the reverse is true. In fact in my experience it has never resulted in a performance gain when compared to fixing application’s architecture. First, consider that browsers will cache images, CSS, and JS files. So these will not reload with every page anyhow. But more importantly people who are thinking along these lines are often looking at iFrames as if they are a poor man’s AJAX. However, the contents of an iFrame paginating is almost always going to be heavier than a true AJAX call which uses XML or JSON to load and refresh only a small parts of the page’s content.

Its just plain difficult to keep stable. There is a large site from a former job of mine which used iFrame extensively. I am not sure where the NDA applies here, so I will not link to their site just to be safe. They use them often, and have all the scripts and fancy tricks used to (in theory) avoid the normal drawbacks of using iFrames. However there are still frequent problems and errors that pop up on their site because of the extensive misuse and overuse of iFrame. There were also frequent customer complaints posted on forums, LinkedIn, Twitter, ect, about the problem this caused them. Just now I jumped over to their site and within a few minutes found a page that gave me an error because of an iFrame issue. These are smart people who know the issues with iFrames well. Yet even they continue to wrestle with it, years later. When iFrames are abused like they are on this site, no amount of fancy scripting will fully resolve the issues that will inevitably arise.

Are iframes considered 'bad practice'?

As with all technologies, it has its ups and downs. If you are using an iframe to get around a properly developed site, then of course it is bad practice. However sometimes an iframe is acceptable.

One of the main problems with an iframe has to do with bookmarks and navigation. If you are using it to simply embed a page inside your content, I think that is fine. That is what an iframe is for.

However I've seen iframes abused as well. It should never be used as an integral part of your site, but as a piece of content within a site.

Usually, if you can do it without an iframe, that is a better option. I'm sure others here may have more information or more specific examples, it all comes down to the problem you are trying to solve.

With that said, if you are limited to HTML and have no access to a backend like PHP or ASP.NET etc, sometimes an iframe is your only option.

Reasons for not using IFrame?

The iframe is a great tool. It enjoys near-universal browser support, it's easy to implement and has a number of useful functions. As with any other HTML element, it can be abused, but wielded intelligently it can play a part in a solid UI.

Some developers might argue to use AJAX instead, and in some situations that may be the more appropriate approach, but AJAX is not a panacea and iframes can be a far simpler implementation which has the same end-result for your users. Do whatever is simplest first, and only change that when you can verify how and why that is not working.

Why are iframes considered dangerous and a security risk?

As soon as you're displaying content from another domain, you're basically trusting that domain not to serve-up malware.

There's nothing wrong with iframes per se. If you control the content of the iframe, they're perfectly safe.

Why developers hate iframes?

Iframes can have similar issues as frames and inconsiderate use of XMLHttpRequest: They break the one-document-per-URL paradigm, which is essential for the proper functioning of the web (think bookmarks, deep-links, search engines, ...).

If you're creating a web application, use whatever technique you want to (including frames, flash, applets, $whatever). If you're creating an actual, informational web page, stick to frameless HTML, CSS and unobstrusive JavaScripts and keep in mind that the page should still be usable with scripting disabled.

Is it bad practice to use iframes? Can iframes be translated into images in the same way canvases can?

However, iframes are not obsolete, but they are frames. Is it considered bad practice to use them?

Sometimes you have to embed a separate HTML document into another, and that is OK. For the record, HTML5 has an entire section dedicated to embedding external content, of which one of the relevant elements is iframe (W3C HTML5).

Of course, whether something is good or bad practice also highly dependent on your use case, but best-practice questions tend to be quite broad by nature.

Also, can iframes be rendered to data:png/base64 or whatever, in the same way canvases can?

As a matter of fact, yes, although IE does not appear to support data:text/html at the moment:

<iframe src="data:text/html,<!DOCTYPE html><html><body><p>abc"></iframe>

However, this is not the "proper" way to do it (even the validators don't agree on whether the syntax is valid — W3C's Nu validator appears to dislike data:text/html because of all the HTML symbols, while Validator.nu only complains about the unencoded whitespace in the DOCTYPE). For embedding raw HTML, you need to use the new srcdoc attribute instead of src (which has even less browser support):

<iframe srcdoc="<!DOCTYPE html><html><body><p>abc"></iframe>

So, in general, specifying raw HTML for iframes is a bad idea for now, and even once browsers start supporting the srcdoc attribute, you should use that over a data URI with the src attribute.

Why do people still use iframes?

I can think of 2 reasons (at the moment) why people would still use iframes instead of AJAX:

1) Iframes circumvent the cross domain origin policy (images, scripts, and styles do not). This can be useful for pulling in sites / content from other domain names relatively safely. Basically, this allows the advantage of being able to visually show data from other domains without letting them stomp all over your page with unlimited access (like something like JSONP would be able to do).

2) You can load multiple types of resources from within an iframe, not just certain mime-types (you're relatively limited to application/javascript, application/x-javascript, text/css, text/xml, image/png, image/jpeg, image/gif with scripts, XHR, images, and sources). For instance, if I want to show you a PDF, I can open an iframe and let the Adobe Reader plugin show you that file. Additionally, in the same domain, if I want to pipeline a script, style, and image all together (inline on the page, image would have to be data URI), I can accomplish this with an iframe (and if it's in the same domain, port, and protocol I can access it with JavaScript as well).

Did you know that Gmail is a set of iframes? The visible part is just clever positioning. Additionally, many OAuth implementation (Twitter, Facebook, Google, Yahoo!) usually use iframes to associate a user on their domain with a successful authentication URL (for after the user logs in).

Is it okay to insert an iframe into the page's content?

As you've discovered, trying to sandbox your CSS from interference, when injecting into the DOM is very difficult without declaratively setting every known style attribute. It's a well documented problem and some solutions can be found in the following posts:

• How do I prevent CSS interference in an injected piece of HTML?

• Is there a way to "sandbox" an HTML block away from its page's CSS without using iframes?

There's nothing fundamentally wrong with dropping your UI it into an <iframe>. I'm not aware of any settings or extension that would block this behaviour.

If your framed UI needs to interact with the DOM on the parent page or a content script you can do so with the use of Window.Parent. Also you may need to consider Same-Origin Policy if your pulling in the UI from another domain.

---

Related Topics