Frames & Iframes
Overview & a Brief History
The web began with pure text pages. These looked very boring, although they were good enough for the engineers and other professionals who first used the web, and for whom the web was initially built for. Browsers too were text based, as were the operating systems they ran on.
The arrival of Windows 95, along with the already present GUI ( Graphical User Interface ) that the Macintosh computers had, rapidly began to change all that. The Netscape company made the first popular graphical browser, the Netscape Navigator, based on the Mosaic browser. Microsoft, although sluggishly slow to catch on, soon realized that the web was not going away, and so began to both try to destroy the Netscape company ( ultimately successfully, more or less, although it's wreckage was salvaged by the AOL corporation ) by first creating, then packaging with its Windows operating systems, the new Internet Explorer browser.
Suddenly the web could have colors, shapes, and textures. And, perhaps most importantly, a web page could have a non-linear mode of data presentation. In other words, a web page could be more than a normal printed page, that was one page, read from top to bottom, or column to column. What made this new way of presenting information was the <frame> tag. With this tag, a page could suddenly be dynamic, and could be composed of several separate web pages.
A popular use of this new technique was to create a page with a navigation bar that did not go away when you scrolled the contents of the webpage. This is done by creating a main frame page that contains two sub-pages, one a page with just the index, pointed to the center, or content page (usually named 'main'). For code examples of how to do this, see our frames page.
Myth number one about frames & iframes:
Search engines can't read them, and visitors can't come into them if they find you via a search engine.
This isn't true, unless you don't code your pages correctly. The key is to always put a link to the content in the noframes part of the code. The search engine will follow this quite happily, as we here at techpatterns.com can testify, since these pages contain many top 10, and some number one, categories, all contained in iframes in this case.
The second part of this myth is also a result of incorrect coding. By using two javascript function calls, one on the content page, and the other on the main, or container page, you can make the browser go to whatever content page you want. It's easier to do this now, with the new DOM 1 standard compliant browsers, but it was possible before. We currently use cookies to do this, other methods proving to be too unstable (especially the get method, placing the data in the url string). The current method is very reliable, and works on almost all > 4 browsers out there that we have tested it on, plus of course the whole Mozilla/Gecko/Konqueror/Safari lines that are being constructed in 2000-present.
The bad guys strike back. Or, don't let programmers make decisions that affect the rest of us.
However, all was not well in web land. This non-linearity was freaking out the programmers, and the people who create the standards that more or less try to govern how the web will function as a lingua franca, a global means of communication. Unfortunately, these people are all programmers, and see the world completely linearly. So to them, a web page should be linear, like their brains, and the code they have spent their lives creating. This is probably because they have pretty much universally spent far too much time staring into computer monitors, and have thus simply lost sight of reality— probably the number one occupational hazard in the computer world.
They began a campaign to eliminate frames from the possible vocabulary of web architects around the world, using a sneaky method of creating the new XHTML standards with frames as a deprecated tag. You can see this with the XHTML 1.0 transitional standards, where it isn't possible to make a framed page that is considered compliant with XHTML 1.0 transitional standards without that framed page having those ugly borders on it. CSS does not allow you any control of either frame or iframe borders. This is not an accident, but an effort on the part of those who want the web to be as linear as they are to make it that way.
XHTML 1 Strict
In XHTML 1 Strict, iframes, frames, and all other features required to make their contents work, like the needed to get the visitor out of the frame to the top layer, are deprecated, which means that if you were to try to make a iframe page in XHTML 1 strict, it would validate as 'Not XHTML' in the W3C's HTML validator, although of course it will still work fine, since no browser treats XHTML any differently from HTML unless you deliver the page with an actual mimetype page header of xml, and even then only Mozilla as far as we know will actually fail to render the page correctly.
Iframes & the Situation Today
However, all is not lost. We now have iframes, a slightly inferior technology. Iframes function more like the img tag, and are inserted into a standard web page. Again, to eliminate that ugly grey border, you have to declare the border as zero in the iframe tag, with this attribute: frameborder="0" inside the iframe tag. To see a code example, look at our iframes page. However, as mentioned above, neither iframes or frames are supported in the w3c.org XHTML 1.0 strict doc type.
Iframes, however, are not nearly as easy or intuitive to work with as frames. Frames allowed sizing of the page relative to the browser window, while iframes have to be manually sized relative to an absolute object of some kind, either using pixel or percentage sizing. This page, for example, is in an iframe contained in a page (the part that is darker blue is the container). It is set to make its height a percent value of its div container, which in turn gets its size from the actual body and html tags, which have been set at body, html {width:100%; height:100%;}
Iframes are not supported at all in Netscape 4, unlike frames, which are supported by every browser out there, so if you need to use iframes and you have Netscape 4 users, you are out of luck, or will have to construct custom NN4 safe pages, which means two sets of pages, which is a total pain, unless you do server-side scripting of the page construction, in which case it doesn't really matter which method you use.
If you would like to see what techpatterns.com, for instance, looks like in Netscape 4, click here. Click the close under the image to return to this page. Notice that there is no content area, just the the text that appears within the iframe tag, and which has the same function as the old <noframe> tag.
What the future has in store for us:
The future actually looks somewhat bright, since once the new CSS 2 overflow:auto; or overflow:scrolling; standards are universally applied in all the browsers out there, along with DOM 1 javascript support, pages will not need to be in iframes in many cases, for single page scrolling content for example, although it's no substitute for a well made iframe container with navigation to different pages. The overflow method allows you to make a page contained in a div tag that has its overflow property set to scroll or auto. This makes that part of your page function like a frame or iframe, although you still won't be able to have hard-coded links from a navigation bar to different content pages. (unlike the above myth about search engines, it is not a myth that search engines do no not execute javascript code, so any navigation that depends on javascripting is not read by the search engines, thus extremely limiting what could be done with overflowing div containers and DOM javascripting that simply changes the div.src to the new content desired.
The simple fact is that there is no subsitute for the grace and simplicity of a well made iframe or frame page, and this is why major sites like Microsoft's technet still use them. There is simply no other way to keep the navigation bar on the left while the content changes to your right without the use of javascript for full functionality, which is a big no-no in web land, since it means that users with Javascript/Ecmascript turned off literally can't access your material, which defeats the whole point.
However, given the limitations of search engines with client side scripting like ECMA/Javascript, the near future does not seem very bright for those who would like to get rid of more fluid web pages and design. But just wait, they'll keep working at it until they achieve their vision of one screen, one page, universally, that screen scrolling down endlessly (too bad people like Dave Raggett and his cohorts will never realize this, but linearity is boring and inhuman, and programming is inherently a linear activity, so it will always be an uphill struggle agains the w3c.org and its uni-linear vision of the web).
Of course, the business world could care less about such things, since they just want their data to flow as efficiently, cheaply, and uncomplicatedly as possible. No one can ever accuse them of wanting the world to be more free, more open, or, heaven forbid, more human.