I have heard countless reasons on why not to use HTML frames, from their lack of accessibility, the general lacking in UX, their being completely inefficient/unmaintainable, or them just being outdated.
This all brings me to two questions:
(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.
(1) No. There are legitimate uses for iframes, where there's no reason to use frames today with modern browsers.
(2) Never use frames; there's other better easier solutions available to produce the same effect.
Use iframes only when embedding the whole site is the most logical option. Although rare, there are occasions when this makes sense.
In short, there's a reason why the frame/frameset/noframe tags are taken out of HTML5, but the iframe will carry over.
(example) If site A is obliged to include a page from site B (proxied to appear to come from site A) then site B css and javascript can and usually will completely hose site A. This is a legitimate reason.
If for some reason you have "nested form".
Say you have a product edit form and inside this form you have an area with another form that let's say allows you to enter a list of the customers to send a newsletter for this product.
Customers are not related to the product at all and has no database relation to a product. They are compliantly separate entities from product.
In this case I crate an IFrame with a customer adding form and submit button that submits the form inside IFrame.
I didn't find any better way to implement the described scenario than using IFrame. And yes, I have a requirement to have both forms on the same page, and newsletter form should be placed inside product editing form. Business need dictated by bosses.
You can use an iframe to give access to ads from third parties in your website without giving them any additional control or messaging to the parent document that contains the iframe.
That way you give access to ads in your site but at the same time protect from attacks from unknown resources
The mozilla dev pages explains it better:
The HTML element represents a nested browsing context, effectively embedding another HTML page into the current page.
