Why developers hate iframes? [duplicate]

问题:

Possible Duplicate:
Are iframes considered 'bad practice'?

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.

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

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.

回答5:

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.

回答6:

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

回答7:

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.

回答8:

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.

回答9:

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.

回答10:

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...

回答11:

iframes of today have a bad name because of iframe support in past browsers. Similar to VB.NET having a bad rap 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.

回答12:

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.

回答13:

HTML elements should not have behavior.

回答14:

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.

回答15:

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

回答16:

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.