Remote Scripting with iframes

Remote Scripting with iframes - Using iframes for Site Navigation
(Page 2 of 4 )

This is a simple example, so let's use my imaginary friend Joe again. He is resourceful but kind of simple-minded. You may recall from part one of this article that Joe is the webmaster for the Web Town Wizards football club.

Joe has received so much praise from the members of the Wizards fan club for the score box that he had put on the Wizards website, that he was getting a big ego. He was beginning to think he could do almost anything using the iframes techniques he had learned. This time, he wanted to do something that would really impress the members.

Joe had seen web pages on other sites where only the content of the center column changed as he clicked on the menu links. He thought that this was really slick, and he wanted the Wizards' site to operate the same way.

He was using a two-column layout with a header and a left column containing the menu links. Joe figured he could make his site work the same as the one he had seen, by putting an iframe in the right-hand column and loading the content of the other site pages to which users navigate into that, instead of into the main window.

First, he created the iframe tag like so:

<iframe src="home.html" name="aname" width = 100% height = 530>

As the source attribute, he used a page called home.html that contained the content he wanted to load into the iframe initially. In part one of this article, we said that the src attribute is required. This is not technically true. Joe could have left out this attribute, but he would have had a blank space in the page where the iframe is, when the page initially loads.

Next, Joe added a target attribute, using the name of the iframe, to each of the menu links on his page. Here is a sample link from his menu:

<a href="anotherpage.html" target="aname">

Now all he had to do was remove the left column and header from the pages that load in the iframe so that they contain only the content he wants in the iframe, and he was done. It looked sort of like this:

Joe tried this, and the page looked pretty ugly, because it had two scroll bars: the normal Windows scrollbar, and an additional scrollbar inside the iframe. Joe found that by making sure that the height of the main parent page did not exceed the height of his browser window, there was no Windows scrollbar, and since the iframe extended all the way to the right-hand side of the page, now the scrollbar within the iframe looked a lot like the Windows scrollbar that it replaced.

This looked pretty good in Joe's browser window, but even Joe realized that in browser windows larger than his, there would be lots of blank space at the bottom of the page, and in browser windows smaller than his, there would have to be Windows scrollbars. Because of this, in order to get the site to look properly on all monitors, Joe had to make all of his pages a fixed size so there would be no scrollbars needed inside the iframe.

You may recall that in part one of this article, we mentioned that the inability of iframes to resize themselves to accommodate content of varying size was a disadvantage for remote scripting. Well this is an example of that disadvantage. This would not be a problem using Ajax request response methods, because they are able to insert the content of the server response into a block-level HTML element such as a <div> that is able to expand or contract, depending on the size of the content.

Joe could live with the problem of having to make all of his pages the same size, but it wasn't really what he was after. It was still a little bit slow because a new page had to load into the iframe each time a menu link was clicked. Joe had an idea to make his site navigation even faster. By now Joe was really getting excited about web design, and he was learning something new, PHP. He saw this as a great opportunity to use his new-found PHP skills to make his site operate  fast and smoothly.

blog comments powered by Disqus