Disadvantages of using frames

I often encounter developers who think it is a good idea to use frames or iFrames to implement web applications. The most often used argument is that with frames you don't have to update the entire window page. This blog post is an attempt to set the record straight and show why it is not a good idea to use frames unless you have to because of legacy reasons etc.

Benefits of using frames

• Navigation can be fixed and always visible without scrolling.
• Logo always visible which can be used to strengthen branding.
• Less payload with page requests as only sections of the windows is refreshed.
• You are able to put anything in the frames making the application seem more integrated or as one without having to open new windows or send the user to new sites.
• If you mess up the markup of your page it might not destroy the entire layout of the site.

Most of the above can be solved without frames using different techniques although some of them would require more advanced technologies such as Ajax or DHTML.

Drawbacks of using frames

• Facilitating search engines is more difficult and the indexing results by search engines are likely to be less good.
• Linking to your site might gets tricky. If you are using frames you might need to set up some javascripts to recreate the frame structure.
• The end user can not use the browser bookmarking or favourite functionality as normal.
• Many people do not know how to copy the actual page address of a page within a frame setup. The end user can not copy the address of the current page from the browser URL address field since it probably just displays the root page url.
• If you do not have full control over who creates pages for your frames you can not be sure that branding and style guidelines are followed.
• Normal navigation for end users with back and forward buttons does not work as expected. (The browser address field is not updated)
• Hyperlinks on the page inside the frames might intentionally or unintentionally open other external content in your frames, degrading user experience and branding.
• Printing the pages gets more difficult.
• Printed pages might loose it's contextual setup such as the breadcrumb trail and it will be difficult for the user to get an overview and find out where the page was printed from.
• Frames might not be supported very well by many types of mobile or other type of compact clients.
• The use of frames increase the chance of multiple and horizontal scrollbars when users do not maximize the browser window or when she has low screen resolution.
• Frames are less usable for handicap users (see WAI/WCAG).
• Page rendering is slower since firing up frames and doing multiple page requests usually takes more time.
• The page rendering might seem unnatural as things are not rendered in a linear fashion.
• You need to make sure hyperlinks all point to the correct sub frames which require additional testing.
• Frames impose restrictions on the graphical design and layout.
• The refresh-button seldom functions as expected.
• You can get into copyright problems or confusion about the origin of content when intentionally or unitentionally presenting external content.
• Many web application frameworks or content publishing systems are not designed for frames and can thus be an obstacle.
• Presenting footer information gets more difficult to present in a consistent matter when using frames (not iFrames).
• The user might experience the site as less trustworthy as the current page URL seems to be cloaked.
• Use of frames is out of date and the site can be perceived as not being modern.
• The use of frames requires more http requests which, to some degree, outweigh the benefits of less byte size payload.
• The end user does not get a clear and consistent confirmation on when a new page is loaded.
• Frames mess up the page metaphor and will make the site more confusing for novice end users.
• If your frames are using session state you might encounter timeout or login forms in the wrong frames which cause a lot of confusion.
• As a developer you might experience problems when the front end code base gets large and cross frames code and other javascripts start to make site browsing seem slow or awkward.
• When using frames it is harder to debug front end issues.

Conclusion

Avoid frames whenever you can. If used, you should definetly know what you're doing and frames should only be used for application type of sites that do not need the typical document/page metaphor.

Dynamic resizing of iFrame, pros and cons

If you are a web developer you have probably encountered iFrame resizing requirements.
Because of legacy code, your portal framework or some other reason you have to use an iFrame and because of the fancy layout from the designer you are required to introduce an iFrame that fills some section of the page that adjusts itself depending on the content that goes into the iFrame, and of course you do not want extra scroll bars appearing on this iFrame and you do not want a vertical scrollbars except from on the outer right side window edge when the page is long.

So how do you go about solving this problem? There is tons of sample code that shows what you can do but you will find few articles summing up pros and cons of alternative solutions.

Basically there are two solutions. I will explain them shortly and present a list of pros and cons. Examples of the two alternatives, I am sure you can find your self. jQuery can be used for both solutions.

Alternative 1) Resize iFrame from within inner frame
Description: With javascript on both the outer page (the one hosting the iFrame) and inner page, iFrame is resized after the inner page has checked its own height and sends this value to its parent. In order to allow cross frame scripting you may need to set the document.domain property on both pages.

Pros:

• We get a scrollbar on the outer most right side (browser window) when the page is long. Same as on all other type of long pages.
• Script only needed on long pages.

Cons:

• Might require changes to browser security settings or modification of trusted sites list.
• When the inner iFrame page has dynamic content (uses ajax/dhtml) that expands the initial page, multiple scrollbars will appear unless you attach your javascript to these dhtml functions.
• Requires that you have control over pages that are to be hosted within the iFrame. javascript must be included on each page (or a shared include/template file).
• Requires setting document.domain property using javascript which might cause future unexpected problems because of dependencies?.
• Both hosted page and parent page need to have the same domain names (not the same subdomain) using the same protocol (http/https).

Alternative 2) Resize iFrame to fit page from outside
Description: Using javascript, iFrame is automatically resized to fit outer window on window load and resize event.

Pros:

• Approach is guarantied to work (if JS is enabled). This means less risk and less chance of bugs.
• Less complex solution and therefore more likely to work over time as you or your IT department do browser upgrades or make changes to browser settings.
• Can be used to show external resources not under your control.

Cons:

• The scrollbar will not span the entire height of the window. Only from the position of the top navigation menu or so and down to the window bottom.
• While resizing the window there will be some flickering and scrollbars might seem sluggish.
• iFrame must span entire width of window, this might put some restrictions on layout design.
• Script to resize iFrame always have to be triggered on page load (and resize) and might contribute to slower rendering on very slow machines.