Frames and iFrames
Frames and iframes allow authors to present documents in multiple views or to present a webpage in the middle of another webpage e.g. places one HTML file in a frame inside a normal HTML file.
Frames and iframes should no longer be used on university websites. Their use has declined since the late 1990s except in certain technical niches where there is little or no alternative. There are several good reasons for this.
Note: In this document, the term 'frame' includes iframes as well.
Reasons to Avoid the Use of Frames
- Slow rendering: Hitting multiple webservers and rendering multiple documents slows a user's progress through a site and tests their patience.
- Content Source: Users may not know what site and/or organisation is responsible for the content.
- Design conflict: When one document is shown inside another, design elements such as styling of links, function of menus, login forms and so on should be consistent. Otherwise the user experience can be very confusing.
- Navigation confusion: Users expect one set of navigation controls, but including another site inside a frame often results in two sets of navigation links and confusion. Users are also accustomed to having back/forward/refresh buttons that apply to the content they are focusing on, but these are often broken by the use of frames.
- A frame inside a frame: Although we try to avoid frames, there are occasions when there is no alternative. It would be confusing if a user browsing a site inside a frame encountered a page using yet another frame. An iframe also makes an assumption about the size of the page it contains. If the page is larger, then either content is hidden or scrollbars appear inside a page that may already have scrollbars. This is confusing to the user and should be avoided.
- Compromised analytics: Visit and bounce rate analytics for a webpage using frames will be much higher than normal as the user visits the page/document in a frame but not on purpose or with intent. When gathering analytics, it's better to know that when a page is visited, that page is all that was being presented to the user.
- Accessibility issues: Not all client software handles frames very well. WCAG 2.0 calls for an alternative means of access to be provided to content that appears in a frame. However, an alternative such as a link to the origin site/document is likely to be a better solution in the first place, so should replace the frame.
- Security issues: If the hosting page is secured by SSL but the iframe content is not, or vice versa, or if they are both secure but come from different servers and so use different certificates, users may see warnings and/or errors that give them reason to doubt the accuracy of the content.
There are times when the use of frames may be required. Non-negotiable 3rd party services such as Facebook, Youtube, Vimeo and Flickr may use content embedding techniques that involve frames, for which there is no alternative.
When a frame is used, it is preferable that it display a single page, or set of similar pages. Links that go outside of this limited set should open in a new window, or be avoided altogether.
Many of the problems with frames are made worse by allowing users to have an extended browsing session within a frame, so it is best to break out of the frame sooner rather than later.
If you think a frame may be appropriate for your site, please contact the Web Team.