COM271, Week 3
Frames
A glance in passing; advantages and disadvantages; frame and frameset properties
Syllabus | Table of Pages | Assignments | References and Useful Links
A Good Idea, Past its Time
A good web developer is conscious that web pages are transferred from server to client one character at a time: the more characters, the more time. Even as internet bandwidth continues to grow, it remains good practice to produce code that is lean and quick. We'll look at web site optimization (for speed) later, after we've mastered the greatest speeder-upper, CSS. But first let's look at a very good idea that is still built into many web pages, but which is probably past its time.
The Frame Element: On a typical site, many page elements remain the same as users navigate from page to page. Site identify comes from repeating page elements on all pages, establishing a common look and functionality that creates a site branding effect. Users appreciate finding common site navigation, so that moving from page to page is smooth, without the trauma (or at least the minor annoyance) of having to decipher unique navigational possibilities each time. Even if a site has a section of several pages that have unique purposes, all pages should have links back to the main site; certainly, users expect to get back to a home page, and on a commercial site, for example, no matter where you are you should be able to easily get to a shopping cart page or to the checkout.
Similarly, the nature of a site usually means encountering common artwork, a familar page banner, an informative footer, and perhaps a persistent column of news features or advertisements (think facebook layout) on the majority of pages. So....
Wouldn't it be a good idea if we could download those common elements once, and leave them in place while we loaded only one part of the page to, say, change content? That's what frames were invented to do! The result was a lot of efficiency, as most of the page could be stored on the client computer ("cached") and used without having to download the entire page again. Brilliant idea, no? Of course, if we allowed our navigation to include links that we wanted to use to change other parts of the page, we'd have to figure out how to do that, too.
An HTML Frame element was meant to be the HTML equivalent of Harvey, the 6' 3.5" pooka from the movie of the same name: Harvey's greatest asset was that he could "overcome all objections," no matter what physical law of the universe was being violated. Here's how it works:
<frameset>: A frame page substitutes the frameset element for the body element. The frameset contains a set of frames. The page will contain no <body> tag.
Frameset attributes include rows and cols, dividing the page into sections for the contained frames:
<frameset cols="20%, 80%"> would prepare for two frames (one row).
<frame>: The frame element itself uses a src attribute to point to an html page (much like the href element of a link). The reference page is loaded into the frame. To allow frames to connect, they also use name and id attributes to create an unique identifier. Reference to the identified frame can then be made by adding a target attribute to a link.
If I had this frame, for example
<frame name="content_frame" >
and this link
<a href="new_content.html" target="content_frame">Load the frame!</a>
clicking on the link would change the contents of the frame, loading the page new_content.html and replacing whatever used to occupy the frame. Pretty slick, eh?
The Trouble With Magic Pookas
I'll try to keep this simple: don't use frames. I added this little section because frames exist and you will see them if you are asked to redesign old sites. Help the web by allowing them to fade away gracefully.
The primary problem with frames is that they do not affect the URL of the page that is loaded. A user cannot bookmark the page and expect to encounter the particular frame that was loaded when the page was bookmarked. You can't copy a URL and email it to a friend and say, "read this!" The page will load with the original frameset and initial frame content...every time! Just as bad, it is not always easy to get pages built of frames to print. The URI ecampus rosters, for example, were built in frames, and at the start of last semester, no one could get their rosters printed. (Even now, the system generates a long explanation of how to get a frame to print: it's in a section available only through authentication, or I'd show it to you.)
If you recall that we can use server-side includes to break our pages into files (the nav.html navigation file, the footer.html footer file, the banner.html .... well, you know), those page components will be downloaded once and, along with images and any other files (externally stored css pages, files of javascripts), stored in the client computer cache. If we download a page that needs the same files, the browser first checks the cache, then cancels the request for that part of the page from the server. We'll use more of these techniques for page modularity shortly. But what we find is that the original good intention of saving downloads really makes no sense now, and there is no strong reason to retain the use of frameset or frame as a standard part of your web development tool chest.
I encourage skepticism on advice such as I am giving here. If you really like the idea of frames, here is a good starting point for further study, the W3CSchools Frames page. I'd only ask that you notice the advice at the top of the page:
ATTENTION. Do not expect frames to be supported in future versions of HTML.
Just sayin'.....