Why is the use of frames and iframes considered bad practice?

Question

Well, I started developing WEB a short time ago, say 1 year. and here in the company we use a lot frames and iframes... I know that in the HTML5 view frames are obsolete, but I still see a lot of people advocating their use..

1. I would very much like to know why they are the subject of so much debate, what are their benefits and harms when it comes to developing..

2. If the frame is obsolete, which is its replacement in HTML5 view?

If for HTML5 frames are obsolete, it must have a plausible answer of why.

Answer 1

The main reason frames and iframes are bad practice is that they are neither accessible nor indexable by search engines.

If a search engine starts to "read" your page and reaches an iframe, it skips that content. He can’t get into the URL and index that other page. It will index separately, so if a person searches the term on the search site, it can fall right into that frame and not the full page.

If a screen reader reads the content to the blind, it will also not be able to read the content from within the iframe.

Frames are not used since use includes or masterpages. Like the frameset served to facilitate maintenance by having the same top, menu and footer file, it makes no sense to continue using something inaccessible and nonindexable if the programming language already renders the page with all the necessary information, always picking up the same file.

Still, they are used in the case of the top bar of portals or youtube videos, for example, because these players depend on other files such as javascript and CSS themselves. Other cases use javascript to call the content, with ajax for example, but this is also not indexable by search robots, nor accessible to the blind (after refreshing the reader does not pass the whole page), but it is easier to manipulate with CSS.

When I make a simple, pure HTML site, I end up using a little PHP just for these includes. It’s easy, simple and all linux hosting runs PHP. It is also easy to run on PC, using xampp for example.

Answer 2

When the frames "glowed"

Frames were often used on static pages where it is not possible to do include on the server.

For example, on a pure HTML site, header, footer and menu should 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 a 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 simply 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 content template by displaying multiple independent pages on the same screen.

This can cause usability problems, mainly because it may not be intuitive for him, especially if he usually uses the back and forth buttons.

Frames are also not very intuitive because they can mix content from different domains and it is not always clear to the user that a particular frame belongs to a different website.

Complexity in development

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

The frame hinders development in several aspects:

• It is often necessary for one frame to communicate via Javascript to another, this can cause problems from XSS to mixing versions and instances of Javascript libraries (like jQuery) in different frames.
• Frameworks Component-based as JSF or Struts may have unexpected behaviors when used in different frames. as they are not designed for this.
• Safety restrictions on general browsers 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 it is necessary to create additional and complex code to make a "global" redirect of the page.

Anyway, the scenarios above were just a few cases that I could remember.

About indexing in search engines

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

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

In this case, many websites used Javascript to check if the main frame was there and, if not, redirect the user to the root of the site. I remember that this used to generate several usability problems.

Exception for iframes

Unlike traditional frames, the iframes have some valid use cases, the main one being to allow the independent rendering of a page location in a secure way, that is, without the content of that site can interfere with the rest of the page.

This technique is widely used in advertising systems (Advertising) digital, such as 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 on the advertisement banner and vice versa.

At Atlassian, products like Jira and Confluence when used in the Cloud cannot have plugins installed directly as in the server version. However, the company has 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 the information selected from the page context. The rest of the communication is done using Restful Web Services and Web Hooks.

So I would say that the main application of iframes today is integration between different web applications safely and independently. This approach tends to grow with the news from HTML5 to create a sandbox more restrictive and therefore safe 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 latest technology to make asynchronous uploads. However, this use tends to disappear as browsers evolve.

Answer 3

I do not consider it a bad practice, but rather 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 have no need to use screen reader, I believe that the use of frames and iframes is not a bad practice.

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

Answer 4

reading these posts I discovered exactly what I was looking for, and now I can say that the use of 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 website that displays ad pad and records the display when the page loads. At the moment, a cookie is generated with the ad id and is only registered after a time, which is determined by the average page display time.

The problem is that the bots "bombard" the sites daily and I could not filter who was bot, or real visitor. I even had an average of the screenings after several reviews, but it was never the real one.

When I modified my system, I started 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, starting to register the views correctly.

For me, the use of iframe was perfect.

Answer 5

1. As already answered here, there are several technical problems (such as 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 in case of framesets for multimedia.

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

Answer 6

It has always been wrong to say that search engines do not index iframes.

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

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

About indexes, the fact is, an iframe, when indexed, does not bring information of which window Parent. Then in the search results (google for example), the direct link to the iframe page will appear. The user falls right into this page and it is only an integral part of another window and can have functionalities that depend on the page Parent.

The problem was just that and recommendations and caution were announced in the use of iframes and SEO. That’s it. Then someone passed the information very carelessly (forums, blogs, etc.) summarizing that iframe was bad practice and period. There the gate burst and could not contain the herd.. rsr.. One copies and passes on what the other put and so the thing was spreading.

Iframe remains useful and has received new HTML5 features. It is a very useful resource for those who know how to use and take care with the misinformations that spread over the internet.

In the case of indexes, to solve the "problem" of opening directly without the Parent page, with a simple Javascript it is resolved to check if there is the Parent page. If it does not exist, redirect it to the Parent page and everything is solved. You should be careful to specify the Canonical, and other tags that indicate that it is a page that has another link to which the indexing should point. This way you avoid being penalized by the search engines. But this is just an extra precaution if SEO is really important to the specific iframe page. If the SEO issue is unimportant, just ignore.

Answer 7

When it comes to accessible development, it’s not that the focus cannot enter iframe, it enters, but it has a behavior problem that differs between browsers. I did it to solve the problem.

Entering the iframe and Leaving 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, it has the Focus directed to a specific part of the internal content 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 independent of the key being used to navigate.