Why Developers Hate Iframes

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.

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.

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.

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 are HTML frames bad?

Frames are more difficult to bookmark and, therefore, more difficult to share with others.

http://www.yourhtmlsource.com/frames/goodorbad.html

When should I use HTML frames?

(1) Not inherently. iframes have many use cases that do not suffer from the problems of frames. They're useful any time you want to mix in a document from another security context, or without the scripting and styles that the parent page is using.

However, it is possible to ‘use an iframe like a frame’: to split the page up into separate iframe areas, with cross-frame-links making a navigational mess that doesn't play well with bookmarks, open-in-new-tab etc.

(2) I would not use frames for anything today. There was a limited use case for them keeping hold of large amounts of page content that you don't want to reload on each navigation. But these days we would just use XMLHttpRequest to update part of the page instead.

Even so, without care taken to make page-changing links accessible (using hash-history and having a static-link analogue for each hash-link, linked with real <a>s that response to middle-click et al), a page that updates/navigates itself using XMLHttpRequest will recreate many of the navigational problems of frames, with strongly negative usability, accessibility and SEO implications.

I find it a bit sad that many authors are creating flashy, swooshy, “modern” animated web sites that, by naïvely using jQuery's load() or similar on its own, exhibit all the worst behaviours of ancient, hated frames.

Why Developers Hate Iframes