As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Getting contradictory messages about that, hope they're not.
I cannot imagine support for it would stop, since a gazillion sites use them.
Some additional questions about that:
Why should they phase out this tag?
Any alternative for it?
Support for <iframe> is still there in HTML 5, so I don't think this will change in the near future.
To answer your other questions:
<iframe>s (as frames in general) are most of the time not user-friendly:
They don't allow easy access of the content in the frame via an URL (without losing the content outside of the frame at least).
Most "technophobe" users are irritated by frames.
As far as I know they are slower to render for browsers
Alternatives include dynamic page generation (SSI, PHP, Rails and so on) and using JavaScript / AJAX to change contents of e.g. a <div>
To be clear: I'm talking about <iframe> as an interface element. Not a hidden element for loading other stuff like e.g. Google Mail does.
In my opinion the W3C jumped the gun in dumping iframes from the Strict HTML and XHTML doctypes. In theory you would use the <object> element to add foreign objects to your document, but browser differences and limitations have made this a nonstarter for many developers. With the much-more-pragmatic HTML 5 (which is still a draft), iframes are back and even have two new attributes: seamless, and the intriguing sandbox.
IFrames are not obsolete, but the reasons for using them are rare.
Using IFrames to serve your own content creates a "wall" around accessing the content in that area.
For crawlers like Google, It's not immediately clear that cotent in an iframe will be ranked as highly as if the content were simply part of the page. For many, this is reason enough not to use it.
It makes the DOM for the IFrame less accessible by tools like jQuery, prototype etc..
Reasons for using iframes:
It's great for walling off other people's stuff from other domains but it doesn't integrate smoothly. (stylesheets, javascript etc...)
Integrating multimedia can sometimes be done easier via an iframe as opposed to using the embed tag.
Really, really specialized cases like gmail's case where they are using it for sounds and history management.
I would also answer that there is no need for the removal of iframes, it's a needed tag and will be around for a while.
Iframes are obsolete for page layout. Never use them instead of good CSS layout, even table-based layout is better.
Good reasons for using iframes are:
ads: adwords for example uses this technique, it is good for encapsulating - ad css won't destroy your page.
hidden iframe: it can be used for hundreds usable things, like tracking, ajax-alternative, etc.
I've seen lots of forums that suggest the Object tag as a replacement for IFrame, which probably works in most cases.
For example, I had a PDF showing in an IFrame (because there were other things we need to show on the page besides only the PDF) and was able to get it to display fine using Object.
What was:
<iframe id="confirmed_pdf" class="current_pdf" src="/prescriptions/show_pdf?id=123" height="570" width="480"></iframe>
Became:
<object id="confirmed_pdf" class="current_pdf" data="/prescriptions/show_pdf?id=123" type="application/pdf" height="570" width="480">
<p>[Show this message if displaying the PDF did not work]</p>
</object>
But Object was not a suitable replacement to fill the requirement to be able to print ONLY the PDF portion of the page.
An IFrame is like its own window within the page (a window within a window, basically), and once you get the window object, you can call .print() on it, like:
jQuery("#confirmed_pdf").contentWindow.print();
IFrame has a contentWindow property, that's what makes printing only that part possible. Object does not have a contentWindow property, so there's no way to print only the section of the page.
So, it seems like if you're just using IFrame to display something, there's other tags like Object that can be used instead. But if you need to interact with the contents of the IFrame in certain ways, then IFrame may be necessary.
IFrames are used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.
IFrames are not dead, but Frameset/Frames are dying.
In the last 2 releases of IE (IE7/IE8) zooming in Frames (not IFrames) has created disastrous results.
By all means use IFrames, but IMHO stay clear of Framesets/Frames.
At my previous company, we provided a hosted application that customers would integrate into their own websites. At times, they would use an IFrame to do this, fitting our hosted page into their existing designs. Sometimes this was even done seamlessly (ie. the IFrame had no borders or scrollbars, it just looked like part of the page). I considered this to be a good use of the tag.
They can be extremely useful in some circumstances, but those are limited. In particular embedding common functionality across multiple sites.
For example I have a client who runs a number of Scottish goods e-commerce sites. As part of this we have developed a couple of simple applications to locate possible clan names from your surname or your choice of tartans (giggle if you wish but tartans are worth $700 million a year to our economy). The database behind this is surprisingly large (nearly ten thousand rows in the core names and tartans tables) and fairly regularly updated.
So we have the applications set up to run on one website and then embedded these into our other websites using an iframe, enabling simple javascript parameter passing so we can integrate the selection of a tartan or clan with functionality on the embedding site. The iframe is set as noborder so it appears completely seamless to the end user.
Of course there would be other ways of doing this, but the use of an iframe is simple and robust. And it's certainly not obsolete.
Horses for courses... <iframe>s are like anything else... for the right purpose they're the right tool; for the wrong purpose they're an ugly hack, or worse.
In Ajax, <div>s are often the more appropriate container. In some places the activity of passing-off external content as part of your own site, as supported by <iframe>s, is inappropriate.
My team used an <iframe> the other day as an ideal way to give users access to their HTML e-mail history - the e-mails were complete <html> pages which we wanted to insert easily into our web template. <iframe>s were absolutely perfect for presenting that data]'.
On the other hand, <iframe>s should almost always be removed or disabled in any user-submitted content which is output back onto the site, because in that context they are a major security issue.
The google gadget specification currently relies on iframes: http://code.google.com/apis/gadgets/docs/spec.html
Currently they are the only simple way to provide isolation for javascript apps that are pulled from multiple domains/providers.
Also many of the widgets that people embed on their websites from third-parties use iframes.
While they do have their drawbacks, iframes provide a pragmatic solution to common problems on the web. I'd have to guess that they will be around for some time to come.
Compliance and Security issues can also drive you to use Iframes; Shopping carts are popular IFrame-based implementations when you want to visually incorporate a shopping cart as part of some web pages without taking on full responsibility for the payment processing side of things.
We commonly deliver an Iframe to integrate our eCommerce stuff and clients like how turnkey it can be.
I work for a company that used frames for everything from pull down menus, lists, content blocks, etc just to cover the intricacies of .net web forms. The application is very slow and only runs on IE. Don't do this.
Related
I really want a way to have one single file for, for example, the navigation bar and the footer so that I don't have to go through all of my pages (only 20 or so, but anyway...) to update it. So I've realized that frames (iframes? What's the difference) can help me with this.
Additionally, I've heard a lot of places that frames are a no-go in web design for some reason. Is this to do with SEO?
Can I use (i)frames safely? Are there alternatives that keep the url http://www.domain.tld/pagename.html ?
Whatever you do, don't use frames/iframes for page layout.
Your best bet is to use a server-side scripting language to build your page. That way, you can have the individual components in separate files (which makes maintenance easy) and then compose them using the scripting language.
So I've realized that frames (iframes? What's the difference)
An iframe embeds a document in the middle of a page.
A frame is part of a frameset, which consists of an entire page.
can help me with this.
They could, but have plenty of drawbacks (mucking up linking, printing, causing scrolling issues, etc). Use an include (e.g. php or ssi) or template system (e.g. template toolkit's ttree) instead.
Adding to these two good answers, from the SEO point of view a frame based site is also might be a bad idea.
Google supports frames and iframes to
the extent that it can. Frames can
cause problems for search engines
because they don't correspond to the
conceptual model of the web. In this
model, one page displays only one URL.
Pages that use frames or iframes
display several URLs (one for each
frame) within a single page. Google
tries to associate framed content with
the page containing the frames, but we
don't guarantee that we will.
See this
As a side note, have yo considered 301 redirect? It is not precisely keeping the same address, rather the opposite but it might be what you want if I understood your concern.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was talking with a colleague about a problem we were having and he suggested that one possible solution was to use an IFrame.
I haven't needed to use an IFrame for he last 5 years and I've done full time web application development, but it made me wonder if the concept of the IFrame and Framesets is something that is supported by browsers for backwards compatibility but really shouldn't be actively used in development any more?
it's one of the major application integration methods for facebook and myspace. and most wysiwyg html editors rely on iframe. thickbox uses iframe. drupal uses iframes. and on and on... so not sure if it's so very simple to just call iframe obsolete. i imagine it'll be actively used for a good long while still...
It's the fastest and easiest way to get any of a number of google services into a web page, where the fuller control of the API integration is not needed.
Like anything else, it is situational. It's far from dead, and there's no reason it should be dead. The web's moving to looser coupling, and IFrame is in line with that.
At best the IFrame isn't ideal for rendering local content, but, like others have said, it is the only way to get external web-content into an application without an API and for that reason it is very important to modern web-development.
No, it shouldn't.
It's a cheap standard way to integrate functionality in a single page. Also allows some useful techniques such as COMET
Not sure if it should be dead. For one of the application I worked on for the manufacturing industry, they wanted multiple tabs to be able to run multiple programs on the same page. Knowing using just regular divs using Ajax would just be a little too much for this intensive app, we used iframes. Of course, it doesn't look like iframes to the end user (using some creative Javascripting and CSS), it looks like just a regular tabbed program.
So, saying it's dead is probably a little too soon unless there are better alternatives.
It's extensively used in ad tracking and conversion tracking; it's one of the easiest ways to put a beacon into a site unobtrusively.
I think that iFrames are not dead yet, they can be used for a lot of things and though they slow the loading speed of a website (with a few miliseconds, depends on the content).
iFrames maybe, Framesets NO. this is what i think. some things can be done only with iframes believe me i searched for another solution for a long time but for eg. a jscript can be used 2 or more times with iframes but when used on a single page it may cause conflicts and sometimes only the first thing that was using the javascript is working.
so sometimes iFrames are the right way to do it, if you can`t do it any other way.
No, its commonly used in junction with AJAX.
For example, on a page where you have ongoing AJAX requests you can't disrupt the response by closing it etc. BUT, you may need to provide a file download on the same page which would normally disrupt the AJAX request. To avoid the conflict, you serve the file download through an IFrame so that the AJAX on the host page isn't disrupted.
That's at least one use case for it =)
Iframes are not dead. They are the only method of fighting several extremely annoying bugs in MSIE (such as div overlapping a <select>), and are widely used in banner exchange networks.
If you consider the fundamental building blocks of the web you will realise that the iframe should never be removed. I have the feeling that many web developers do not properly understand the concepts of data centric systems and prefer to work in a procedural, top-down, application centric manner. There are many things done with async HTTP requests and Javascript that should simply use an iframe.
There are two fundamental concepts when it comes to linking content in a data centric world like the web - cross referencing and embedding. Hyperlinks are used to cross reference data while iframes are used to embed data. URLs are used to reference data in both cases.
A simple example is linking to an image. Cross referencing an image would be done as follows:
Link to the image
While embedding an image would be achieved as follows:
<iframe src="someImageURL" />
Of course you could use the "img" element to embed an image instead, but that is specific to images... I vote that the "img" element be removed in favor of using the more generic and flexible iframe.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I haven't used frames since 1998. They seem like a bad idea and in all my development I've never had a situation where frames were the right solution, or even a decent solution.
However, I'm now working with an internal web application written by another group and the entire site is built in a - header, left side menu, right side content - frameset.
For one, when VPN'd to my network I constantly get a "website.com/frames.html" cannot be found." error message. This doesn't happen when I'm on the internal network.
Second, the app has a built in email/messaging system. The number of unread messages is shown in the left side menu frame as "Messages (3)" but the count doesn't update as I read the messages. The developer told me since it was in a frame I needed to right click on the menu and 'Refresh'. Seriously????
So, my programming related question is, what reasons do you have for not using frames in a website?
Although they solved a problem at the time they were created (updating part of a "page" while keeping in place a non-updating part), framesets were criticised in terms of usability pretty much from the start, as they break generic functions of the browser, such as:
bookmarking, and copy-and-pasting URLs to share
printing the page as displayed on the screen
reloading the page: since the URL has generally not changed, you will often be taken back to the site's homepage or default frameset; manually reloading some frames is possible, but not obvious to the user
back and forward buttons are ambiguous: undo/redo the last frame change, or take you to the last time the URL bar changed?
The heaviest burden of avoiding framesets - including the same content on every page - is trivial to solve if you are using any server-side language to generate your HTML, even if all it provides is a "server side include". Unlike framesets, a server-side include could occur anywhere on the page; building a site with a server-side scripting language or templating system has other obvious advantages too.
There is still an advantage to being able to update small areas of the page without reloading the entire content, which can be achieved via AJAX. This sometimes leads people to create interfaces with all the problems of framesets outlined above, but that is hardly an argument in favour of framesets. Again, a site built with well-designed AJAX functionality can achieve things which framesets don't even begin to address.
One good reason to avoid frames today is they have been deprecated in HTML 5: Chapter 11 Obsolete features
11.2 Non-conforming features
Elements in the following list are entirely obsolete, and must not be
used by authors:
[...]
frame
frameset
noframes
Either use iframe and CSS instead, or use server-side includes to
generate complete pages with the various invariant parts merged in.
The #1 reason? Users hate them.
Even if they offered advantages in other areas (separation of code, application design, speed etc) they are part of the user interface. If users don't approve, don't use them.
Frames were vaguely useful when you had a static web site, to avoid repeating navigation menu in all pages, for example. It also reduced the overall size of a page.
Both these arguments are obsolete now: sites don't hesitate to serve fat pages, and most of them are dynamically built so including such navigational parts (or status, etc.) has no problem.
The "why" part is well answered above, partly by your own question (you hit a limitation, although it can be overridden with a bit of JS).
My number 1 reason not to use frames is because they break the bookmark (aka favorite) feature of browsers.
With the technology that exists today, frames have become obsolete. But if your legacy project still uses them, you can make the messages update with some ajax.
Just because of the cell phone iPad craze doesn't mean that highly functional full featured sites are suddenly "obsolete", and those who decided to make framesets obsolete seem to be the same complainers who never figured out their full potential in the first place, or maybe they're the lobbyists of the mega-corporate cell-phone and tablet makers who couldn't be bothered to make a decent frames capable browser for their itty-bitty screens.
Admittedly, iFrames can handle simple jobs like scrolling and/or displaying independent segments within a single page pretty well, and I use them for that inside my own frames based website, but to get them to work as well as the foundation for a site itself is a nightmare. Trust me, I know because my website is one of the most sophisticated frameset based sites on the Internet and I've been looking at the pros and cons of transposing it all to iFrames. Nightmare is an understatement.
I can already hear the whiners saying, "Well why did you build it that way in the first place then?" ... and the answer is A: Because I'm not lazy. and B: Because a frames based site is the most functional, visually appealing, and user friendly format for an information based site with hundreds of pages of content that doesn't have to rely on a server. By that I mean all but the external advertising can be viewed straight off a flash drive. No MySQL or PHP needed.
Here's some of the issues I've encountered:
The objection to orphaned pages can be easily handled with JavaScript.
The objection regarding bookmarking is irrelevant unless you use no frames all.
Content specific bookmarking can be handled with an "Add Bookmark" JavaScript function
The objection regarding SEO is easily handled by an XML sitemap and JavaScript.
Laying out dynamically sized frames is far easier and more dependable with standard framesets.
Targeting and replacing nested framesets from an external frame is easier with standard framesets.
In-house scripts like JavaScript searches and non-server dependent shopping carts that are too complex for cookies don't seem possible with iFrames, or if they are, it's way more hassle to get them working than using standard frames.
All that being said, I like the single page appeal of iFrames, and when they can actually do all the same stuff for my site as easily as standard frames does now, then I'll migrate. In the meantime, this nonsense about them being "obsolete" is as irksome as the other so-called "upgrades" they've foisted on us over the years without thinking it all the way through.
So what does all this boil down to for the question of whether or not to use framesets? The answer is that it all depends on what you want your site to do and on what platform it will mostly be viewed on. At some point it becomes impractical to make a multi-page site work well without some frames or iFrame integration. However if you're just creating a basic profile page that displays well on a cell phone or tablet, don't bother with framesets.
They almost always make people angry. What more do you need?
Frames are really useful in some occasions. If you are creating a local webpage that serves only for reading, no interactivity involved and the website will not be public on the internet, all the reasons on not to use frames are removed. For example a user manual for an application that is developed solely in html, frames are really useful in keeping a table of contents on the left in a simple and easy to code way. Also if you have proper navigation within the website then the back button ambiguity is removed completely
This question already has answers here:
Closed 13 years ago.
Possible Duplicate:
Does it make sense to use the <table> tag on a “modern” website?
Everywhere I go I see don't use table layout, it's evil, even Google says that, so why one of the most visited websites, Google and Twitter, use it for their homepage?
I don't think it is any kind of mistake, or any other stupid problem.
The only reason I can think of is, that they want the page to look similar even if client doesn't support CSS, like with Lynx.
So why everyone say it is so bad, if the biggest websites on the internet use it.
In my opinion, there are some cases, like those mentioned above, where it is vitaly important to have the same look everywhere, than it is OK to use tables.
edit: The same question goes about html elements like <center>, or formatting text with attribute align and other "html attributes and elements used to substitute CSS functionality"
Page load time is king for these guys, and bandwidth usage is extreme.
I'd have to say they use tables for raw data speed, since they are serving up so much bandwidth every day.
Also, notice that they use inline styles in the page header to reduce the number of HTTP requests to help speed up page load time.
Table layout gets more grief than it deserves. It's easy for developers to use, it's consistent across nearly every web browser, and it allows you to easily add rows/columns with little to no effort.
The only downside is that it goes against the mantra that your document should only contain content, and your design should be contained separately (in a CSS file).
Google doesn't have to care about ranking high in search engines... ;)
Yep, agreed. Sometimes, just sometimes tables are just fine. Not everyone is writing websites that are targeted at every possible browser, that needs to support text to speech etc. In general, try to learn and grow your skills and use CSS positioning etc, but nothing bad will happen if someone uses a table to position things on a webpage.
Maybe this question should be community wiki, though?
It's evil, it's a pain, but rendering is pretty much guaranteed to be consistent across different browsers.
Table layout is working on most browsers. Google and others want to reach all user, not some or only modern users. Having different layouts or layout technologies is hard to maintain and costly in delivering content.
Table layout is not tricky. Its straight forward. You dont have to look for css hacks, browser incompatibilities or others.
Table layouts are bad. Because thy mix layout and content.
Twitter works pretty well from phones in web mode. Some web browsers are truly gruesome, so I assume Twitter does what it has to.
Given how poorly so many web sites work on phones, I'm more concerned about mobile compatibility than with the concerns of CSS evangelicals.
Three main reasons:
Tables are mainly bad for search engine reasons (there's also the issue of them messing up the DOM a bit, but that's not too bad). People don't search for Google on search engines, and people don't search for Twitter posts on generally either.
Tables render consistently on nearly every browser, including smartphones (which is a big concern for Twitter especially).
Tables consume less bandwidth. Both sites have immense data loads and need every bit of speed they can get.
Browser Support - These guys need to have their websites render perfectly on ALL web browsers (New, Old and Obscure). No matter who's using their websites and what OS/Browser their using, these websites need to work.
Each web browser supports it's own implementation of CSS and this causes a similar issue to that of the JavaScript DOM support in various browsers.
Page Load Time - Also their pages are optimized for Page load times. If it takes a user too long to load the page they'll just go somewhere else. There are still plenty of users without broadband, even a lot of mobile devices don't have very fast connections depending on where you are.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
The community reviewed whether to reopen this question 6 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
Somewhere along the line I picked up the notion that using iframes is 'bad practice'.
Is this true? What are the pros/cons of using them?
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.
They're not bad practice, they're just another tool and they add flexibility.
For use as a standard page element... they're good, because they're a simple and reliable way to separate content onto several pages. Especially for user-generated content, it may be useful to "sandbox" internal pages into an iframe so poor markup doesn't affect the main page. The downside is that if you introduce multiple layers of scrolling (one for the browser, one for the iframe) your users will get frustrated. Like adzm said, you don't want to use an iframe for primary navigation, but think about them as a text/markup equivalent to the way a video or another media file would be embedded.
For scripting background events, the choice is generally between a hidden iframe and XmlHttpRequest to load content for the current page. The difference there is that an iframe generates a page load, so you can move back and forward in browser cache with most browsers. Notice that Google, who uses XmlHttpRequest all over the place, also uses iframes in certain cases to allow a user to move back and forward in browser history.
It's 'bad practice' to use them without understanding their drawbacks. Adzm's post sums them up very well.
On the flipside, gmail makes heavy use of iFrames in the background for some of it's cooler features (like the automatic file upload). If you're aware of the limitations of iFrames I don't believe you should feel any compunction about using them.
Having worked with them in many circumstances, I've really come to think that iframe's are the web programming equivalent of the goto statement. That is, something to be generally avoided. Within a site they can be somewhat useful. However, cross-site, they are almost always a bad idea for anything but the simplest of content.
Consider the possibilities ... if used for parameterized content, they've created an interface. And in a professional site, that interface requires an SLA and version management - which are almost always ignored in rush to get online.
If used for active content - frames that host script - then there are the (different) cross domain script restrictions. Some can be hacked, but rarely consistently. And if your framed content has a need to be interactive, it will struggle to do so beyond the frame.
If used with licensed content, then the participating sites are burdened by the need to move entitlement information out of band between the hosts.
So, although, occaisionally useful within a site, they are rather unsuited to mashups. You're far better looking at real portals and portlets. Worse, they are a darling of every web amateur - many a tech manager has siezed on them as a solution to many problems. In fact, they create more.
Based on my experience a positive side for iframe are when calling third party codes, that may involve calling a javascript that calls a has a Document.write(); command. As you may know, these commands cannot be called asynchronously due to how it is parsed (DOM Parser etc). An example of this is http://sourceforge.net/projects/phpadsnew/ I've made use of iframes to help speed up our site as there were multiple calls to phpadsnews and the site was waiting for the response before proceeding to render different parts of the page. with an iframe I was able to allow the site to render other parts of the page and still call the Document.write() command of phpads asynchronously. Preventing and js locking.
There are definitely uses for iframes folks. How else would you put the weather networks widget on your page? The only other way is to grab their XML and parse it, but then of course you need conditions to throw up the pertenant weather graphics... not really worth it, but way cleaner if you have the time.
The original frameset model (Frameset and Frame-elements) were very bad from a usability standpoint. IFrame vas a later invention which didn't have as many problems as the original frameset model, but it does have its drawback.
If you allow the user to navigate inside the IFrame, then links and bookmarks will not work as expected (because you bookmark the URL of the outer page, but not the URL of the iframe).
It's worth noting that iframes will, regardless of the speed of your users' internet connection or the contents of the iframe, cause a small (0.3s or so) but noticeable slowdown in the speed your page downloads. This is not something you'll see when testing it locally. Actually, this is true for any element added to a page, but iframes seem to be worse.
When your main page loads in HTTP protocol and parts of your page need to work in HTTPS protocol, iFrame can beat jsonp hands down.
Especially, if your dataType is not natively json and needs to be translated on server into json and translated on client back into e.g. complex html.
So nope - iFrame is not evil.
They are not bad, but actually helpful. I had a huge problem some time ago where I had to embed my twitter feed and it just wouldn't let md do it on the same page, so I set it on a different page, and put it in as an iframe.
They are also good because all browsers (and phone browsers) support them. They can not be considered a bad practice, as long as you use them correctly.
I have seen IFRAMEs applied very successfully as an easy way to make dynamic context menus, but the target audience of that web-app was only Internet Explorer users.
I would say that it all depends on your requirements. If you wish to make sure your page works equally well on every browser, avoid IFRAMEs. If you are targeting a narrow and well-known audience (eg. on the local Intranet) and you see a benefit in using IFRAMEs then I would say it's OK to do so.