IFrames (HTML)是否已过时？

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 used a lot with AJAX. GMail for example, uses nine hidden IFrames I believe.

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:

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

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.

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.

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.

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.

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.

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.

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.

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