views:

2950

answers:

17

While working with web developers, I always hear from them that using iframes is something we must avoid as we can, and some say it's something bad, annoying and makes a lot of problems.

Also when i told my previous boss "not a developer" one day that i will use iframe, he looked at me as a bad developer :)

What i want to know, does iframes have a very bad history with web development?

Is it a disaster?

In some cases I see that it's a must to use iframes, is saying that means I am a bad developer?

Or all of that because of it's hard to deal with because of some security issues we must take care about while developing?

Please list your points if you hate it too or correct me if I am thinking the wrong way.

+3  A: 

iframes of today have a bad name because of iframe support in past browsers. Similar to VB.NET having a bad wrap due to VB6 history. I use them these days where needed...just keep in mind that it is possible for it to not work as you had planned every now and then and to account for that.

Andrew Siemer
+5  A: 

I think people confuse iframes with HTML frames, and frames are pretty universally despised.

People use iframes all the time without even realizing it. If I recall correctly, TinyMCE uses iFrames.

Nosredna
+1  A: 

I guess because it goes against the whole html-describes-contents + css-does-the-visual-design fundamentalism. Also overuse of iframe is waste of performance since it's making separate calls to fetch the frame. If you think about it AJAX basically is like iframe, except it's trendy today (may not be in the future).

Security wise, it kinda is problematic because the user could load total crap from other domain without even knowing.

eed3si9n
A: 

Because they can be tough to work with when it comes to security. A well-behaved, modern browser does not let you write code in a iFrame which manipulates elements in other iFrames on the page. This can make certain techniques tough to achieve sometimes.

Dave Markle
the most important security mechanism in browsers is the same-origin-policy: as long as the documents are available under the same domain, there's nothing wrong with cross-frame scripting
Christoph
+11  A: 

As Nosredna said, it's probably because people confuse them with frames, and there are actually a lot of valid arguments against frames. Some of them aren't applicable to iframes, but then again some of them are.

The most striking such issue is probably that of deep linking: It's true that iframes suffer from this to a lesser extent than frames, but if you allow your users to navigate between different pages in the iframe, it will be a problem. There's also a couple of usability problems that you'll have to watch out for. The most common examble is that of double scrollbars, which I personally find incredibly annoying.

I tend to avoid iframes, mostly because I find it to be an unelegant solution. I've found that when I actually sit down and think about it, there's almost always a better solution. Despite that I also believe that there is a place for them. It's the goto of the web world: Just because it has a history of being misused, it has become consensus that it shouldn't ever be used. That really isn't the case here, but I do believe that you should think twice before using iframes.

Emil H
+29  A: 

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.

Christoph
I agree with that. RIAs are going to be JavaScript-heavy. A web page in the traditional sense should work with JS turned off.
Nosredna
Doesn't it depend on exactly what it is you're 'iframe'ing? The side-effects of including an entire page in an iframe are quite different from those that arise when including a 'widget' or navigation element.
Bobby Jack
Iframes are a must when you're building something that must notbe changed by the current page CSS style.
vsync
Maybe I'm jumping the gun a little here, but I think it's ok to require your users to have JS these days. Are users willing to miss out on Google Maps? There might be a static version of it, but being able to pan and zoom with the mouse really defines the GMaps exp.
allyourcode
@allyourcode: if you look at the popularity of the NoScript FF add-on and judging from my own browsing behaviour (js + flash disabled by default), making your site usable without scripting isn't unreasonable; you'll have to do it anyway to account for search engines...
Christoph
@allyourcode: not necessarily okay -- google maps is never going to work in ELinks. (Of course, [i]frames probably never will either.)
SamB
@allyourcode: Google maps is a typical web application, and as **Christoph** said; in web applications you can use whatever technology you like. But for plain informative pages, everyone should be able to read it properly without having any fancy technology enabled.
awe
@awe agreed, but you're probably not going to invest the time to put lots of fancy scripting on pages that are just informational. For more interesting pages, you're going to want to do things that can't be done any other way. In that case, if you want a functional app for nojs users, it has to be completely different, and will inevitably not be as fun for the user.
allyourcode
+6  A: 

One reason is security -- iframe injection attacks were pretty common. See this Ars Technica page for a description:

http://arstechnica.com/security/news/2008/03/ongoing-iframe-attack-proving-difficult-to-kill.ars

and another page that summarizes some vulnerabilities (I don't know how many of these are valid for the current crop of browsers, but the article's not that old):

http://www.thespanner.co.uk/2007/10/24/iframes-security-summary/

On the other hand, they enable cross domain communication, and are used quite commonly by "ajaxy" webapps:

http://softwareas.com/cross-domain-communication-with-iframes

ars
+2  A: 

One problem is that they have their own page lifecycle so interactivity between host and iframe child is limited (query string, session variables or JS). An alternative would be to consider using a scrolling div.

Another problem is printing. The output of an iframe (or a scrolling div for that matter) can be unpredictable and varies wildly between different browsers.

Troy Hunt
I agree. I've been working on printing the content of an iframe for about a week now, and it's anything but consistent.
Dave
At least with a scrolling div, it doesn't have to be a scrolling div when printed...
SamB
+1  A: 

HTML elements should not have behavior.

geowa4
+2  A: 

One reason they're rejected is because they're inherently slow. By the time the iframe begins loading its host page is already in an advanced stage of the loading pipeline. Iframes and snappy browsing are almost impossible to combine.

Joeri Sebrechts
A: 

You shouldn't use iframes for design. CSS does a way better job for the same thing and allows a lot more liberty too.

Partial
+8  A: 

I wanted to add that most of the time, iframes don't help SEO of a page either. Googlebot doesn't put the content of an iframe on the page.

marcc
Nice important point
Amr ElGarhy
+3  A: 

There is one situation where iframes are (almost) required: when the contents of the iframe is in a different domain, and you have to perform authentication or check cookies that are bound to that domain. It actually prevents security problems instead of creating them.

For example, if you're writing a kind of plugin that can be used on any website, but the plugin has to authenticate on another domain, you could create a seamless iframe that runs and authenticates on the external domain.

Philippe Leybaert
This is indeed why I am looking to use them.
Nicholas Leonard
A: 

It's bad practice, and a lazy way of writing good (read: does what the customer wanted) code. A search for "iframe bad" on Google (without quotes) brings up many forum discussions on the topic. If you really need to bring in external content, use AJAX. Better yet, don't do it at all.

thezachperson31
+2  A: 

Also found these questions which should complete the answer:

Why Do Some People Say Iframes Are Pure Evil?

Are iframes considered ‘bad practice’?

Are iframes a terrible idea?

Amr ElGarhy
+1  A: 

I think IFrames have their place. I wouldn't use them on front-end/public-facing web-sites due to problems with SEO etc. For an internal/back-end web-app I think they are useful when you need to isolate the styling of a particular section from the rest of the page, e.g. a report viewer or an HTML editor, where inherited styles from the parent page could cause a problem if all the content was in one document. My 2c...

JonoW
A: 

There is nothing wrong with Iframes for building web applications. They allow a combination of targeted content with memory encapsulation. How many times did someone build some slick little javascript ajax thing that totally blew chunks when they forgot and uploaded the latest Jlibrary to their parent page or some DIV loaded content? Most of the other issues surround SEO which only matter if you actually wanted to steal someone elses content which is pretty dumb anyway. Iframes give you encapsulated memory and the ability to share well designed pages across multiple sites. Despite what many would have you believe, Iframes and or their equivalents will be around for a very long time.

TheRealWorld