When the frames "shone"

Frames have been used a lot on static pages, where it is not possible to make include on the server.

For example, on a pure HTML site, header, footer, and menu must be repeated on each page. This was a big problem and the frame solved it perfectly, as well as saving on loading time.

Software like Dreamweaver mitigated this problem by allowing us to generate all pages of the site from template, changing only the content of each of them.

Today, where any server has at least PHP, it is better to use some CMS (Content Management System) or simple includes to build the page and automatically add each necessary element to it.

Lack of pattern

frames are also bad because they break the traditional web model of content, by displaying multiple independent pages in one same screen.

This can lead to usability issues, mainly because it may not be intuitive for him, even more so if he often uses the back and forward buttons.

Frames are also unintuitive because they can mix content from different domains and it is not always clear to the user that a given frame belongs to a different site.

Development complexity

In my own experience working with banking systems I see that using frames often generates problems at some point.

Frame makes development difficult in several aspects:

• it is often necessary for one frame to communicate via Javascript with another, this can cause various problems, from XSS to mixing versions and instances of Javascript libraries (such as jQuery) in the different frames.
• component-based Frameworks like JSF or Struts can have unexpected behaviors when used in different frames. for they are not designed for this.
• security restrictions in browsers general crashes and unexpected behaviors.
• redirects resulting from actions in the system do not work well in frames, since only the frame would be redirected. Often you have to create additional and complex code to make a "global" redirect of the page.

Anyway, the above scenarios were just a few cases that I managed to me remember.

About search engine indexing

The search engines could identify the various frames (if they were static) or at least through some site Map.

As already mentioned, there was a problem when a visitor entered the site directly on one of the pages that is not the main frameset .

In this case, many sites used a Javascript to check if the main frame was there, and if not, it redirected the user to the root of the site. I remember this used to generate several usability issues.

Exception for iframes

Unlike traditional frames, iframe s have some valid use cases, the main one being to allow the independent rendering of a page location securely, that is, without the content of that location being able to interfere with the rest of the page.

This technique is widely used in advertising systems ( advertising ) like Google AdSense.

The advantage of iframe is that it does not slow down the main site and does not allow the site to change information in the advertising banner and vice versa.

At Atlassian, products such as Jira and Confluence when used in the cloud cannot have plugins installed directly as in the server version. However, the company developed the technology called Atlassian Connect which consists precisely in the possibility of extending the products by adding frames in strategic locations that receive only selected information from the page context. The rest of the communication is done using RESTful Web Services and Web Hooks.

Therefore, I would say that the main application of iframes today is integration between different web applications securely and independently. This approach tends to grow with the new features of HTML5 that allow you to create a more restrictive sandbox for certain uses.

Some libraries also use iframes to simulate AJAX requests when the browser does not support certain features. For example, the jQuery File Upload does this to submit files if the browser does not support the most modern technology for asynchronous uploads. However, this usage tends to disappear as browsers evolve.

I do not consider it a bad practice but tools that can be used in certain situations, as well as div and other new technologies will be used as needed. For example, if I need to create a simple intranet with few resources and in a short time and that is independent of indexing by robots and I do not need to use a screen reader, I believe that the use of frames and iframes is not a bad practice.

Old tools do not cease to be tools, just become more of a tool option in a need.

Reading these posts I found out exactly what I was looking for, and now I can say that using iframe in some situations is better. For example: content not accessible/indexed by search engines, as Marta cited.

My problem was solved with the use of iframe as follows:

I have a site that displays ad block and logs the display when the page loads. At the moment, a cookie is generated with the ad id and is only registered after a while, which is determined by the average viewing time of the pages.

The problem is that bots "bombard" sites on a daily basis and I couldn't filter who was a bot, or actual visitor. I even had an average of the views after several analyzes, but it was never the real one.

When I modified my system, I went on to display the banners through an iframe that included the script that was on a separate page. After that, I realized that the number of views dropped dramatically, moving to log the views correctly.

For me, the use of iframe was perfect.

1. as already answered here, there are several technical problems (such as, for example, accessibility).

2. I will put here several possible substitutes for frames and iframes:

   • div: making good use of CSS and DOM manipulation, divs basically become more flexible framesets.
   • canvas: ideal for multimedia framesets.

In short, framesets were good options at the time when we didn't have as many ease with JS and CSS. Today we already have much better solutions if we make good use of all the tools at our disposal.

It has always been erroneous to claim that search engines do not Index iframes.

The problem is the way this information has been passed on in a sloppy way over the years.

Since the framesets are actually deprecated, I will comment only on the iframes.

About indexings, the fact is, an iframe, when indexed, does not bring information of which window parent. Then in the search results (google for example), will appear the direct link to the page of the iframe. The user falls directly on this page being that it is only an integral part of another window and may have features that depend on the parent page.

The problem was just that and recommendations and caution in the use of iframes and SEO were announced. That's all. Then someone passed the information very carelessly (forums, blogs, etc) summarizing that the iframe was bad practice and period. Then the doorman burst and there was no way to restrain the float.. rsr.. One copies and passes what the other put and so the thing was spreading.

IFrame remains useful and has received new features in HTML5. It is a very useful resource for those who know how to use and take caution with the misinformation that spreads over the internet.

In the case of indexing, to solve the "problem" of opening directly without the parent page, with a simple JavaScript it is solved by checking if the parent page exists. If it does not exist, it redirects to the parent page and everything is resolved. Must be careful to specify the canonical, and other tags that inform that it is a page that has another link to which the indexing should point. This avoids being penalized by search engines. But that's just extra care in case SEO is really important to the specific iframe page. If the SEO issue doesn't matter, just ignore it.

In terms of accessible development, it is not that the focus can not enter the iframe, it enters, but it has a behavior problem that differs between browsers. I did this to solve the problem.

Entering the iFrame and exiting the iframe, are non-visual parts of the code accessible through screen readers, where when receiving the focus, either through the use of the key tab or navigation arrows, the same has the focus directed to a part of the internal content specifies inside or outside the iframe.

If we analyze, some pages that have the accessibility feature, do not standardize their flows, for example, the ideal is that the flow does not undergo change regardless of the key being used to navigate.