The best way to FRAME-proof your pages, boost table speed, & more

2 free Perl scripts that add HEIGHT & WIDTH to IMG tags automatically

By Chuck Musciano

NetscapeWorld
has become

May 1997

Table of Contents

Topical Index

Summary
Never say never, especially on the net. It's a lesson I learned long ago while inciting flame wars in various news groups. A lesson I promptly forgot when putting together my March column. I foolishly claimed that it was impossible to keep your pages from being loaded within someone else's frames, inciting dozens of people to point out exactly how wrong I was. I'll offer a weak defense and then share their tricks, along with some page performance tuning tips, a nifty image handling tool, and one last image-width hack. (1,700 words)

Stop the barrage of e-mail! I give: you can frame-proof your pages, keeping them from being captured by the frames on another page that links to your site. In my defense, I did claim that frame-proofing is impossible using HTML. All the solutions I received used JavaScript to escape from frames. Since JavaScript is technically not part of HTML, I feel somewhat vindicated that my answer was correct, although of little use to the majority of my readership.

To recap, a reader wrote complaining that their beautiful pages were being referenced from within frames on other sites. On those sites, the link to their site did not contain a target=_top attribute, causing their pages to be squeezed into a frame within the linking page. The result was ugly and bothersome, especially since the reader's pages were being diminished by someone else's HTML shortcomings. How could he keep this from happening?

The answer lies not in HTML, but in JavaScript. It only takes a few lines of JavaScript to detect the presence of frames and to then remove them.

I was struck by how many different ways authors had come up with to detect that frames were being used on the current page. All of the following JavaScript conditional expressions will test to see if frames are in use:

if (self.location != top.location)
This tests to see if the document location of the current document matches the location of the top-most document on the page. If frames are being used, that top-most document will have a different URL and the test will succeed. If there are no frames, the top document and the current document are the same object and have the same location URL, indicating that frames are not being used.
if (self != top)
This is a more general version of the first condition. Instead of testing the document location, simply check to see if the current document is the same object as the top document on the page. If not, frames are being used.
if (top.frames.length > 0)
The top document has an object that contains all the frames in use on the page. Within that object, the length member keeps a count of how many frames are currently defined. If that count is greater than zero, frames are being used. It is also possible (and more elegant) to write this condition simply as top.frame.length. Since any non-zero value in JavaScript (like C) is equal to "true", a non-zero frame count returns a true value as well.
if (top.frames[0].name != "name")
This is a more specific test that only works if your page contains its own frames. In that case, you can test the name of a specific frame to see if it matches that frame in your document. You'll need to replace the 0 in the condition with the number of a suitable named frame in your document, and replace the "name" with the name of the frame. If the names don't match, your frames have been captured within another set of frames.

Once you detect that they are in use, breaking free is easy. Simply set top.location to your document's URL. When this property is changed, the browser will reload the document into the top-level browser display, removing all the frames and replacing them with your document.

Readers were split in setting top.location, relying on two principal methods:

top.location = "URL"; top.location = self.location;

The first sets the location to an explicit URL which you must provide. The second uses the URL of the current page. I prefer the second method, since you need not ever update the URL if the page moves or changes its name. The first version will require ongoing maintenance as your site grows and evolves.

The last piece to the puzzle is adding this snippet of code to your documents. We put this down with the onLoad attribute of the <BODY> tag. The JavaScript fragment assigned to this attribute is executed as the page is initially loaded by the browser. This means that the page can detect the presence of frames almost immediately, before your page is fully presented to the user. Since a change to the top.location property results in an immediate reload, you'll break free of the frames almost instantly.

Collecting all my favorite pieces of the puzzle, I offer this version of the <body> tag to frame-proof your pages:

<body onLoad="if (self != top) top.location = self.location">

Add all the other attributes to it, of course, and give it a try in your pages. If it doesn't work, I'm sure to hear about it.

How can I speed up my pages?

Also in March, I discussed how image size and frequency of use affects the overall speed at which your pages are downloaded. Hal Pawluk wrote to share some useful tips and tricks on improving the speed of any page, even those with small amounts of graphics. He has collected those tips on a page of his own; I'll cover a few of the more important ones here.

Most modern browsers are designed to show as much content as possible to the user as quickly as possible. This means that as soon as the browser can render the content of the visible portion of the page, it will do so, downloading the remainder of the page as you read the first portion.

The browser cannot lay out a page until the sizes of all the objects in the page are known. This means that the browser needs to know the sizes of all the images in the page, and the sizes of all the tables. Images are easy: just add the height and width attributes to each <img> tag in your page. The browser will use those sizes to allocate space for the image, instead of downloading the image to determine its size.

Tables are more of a problem. The browser must scan the entire table to determine how many columns are in the table, and then must render each cell in the table to see how wide each column must be. You can help this process a bit by adding the cols attribute to the <table> tag, telling the browser how many columns you intend to create. Sizing the table cells is harder to make faster, since the browser must read the entire table before making any decisions. If your page consists of one giant table for layout control purposes, it may take a long time for the browser to display just the first portion of your document.

Hal's suggestion is to split your table into two pieces: a smaller table that loads quickly and fills the first visible portion of your document, and the larger remaining portion which can be loaded while the user reads the first section. This suggestion keys on the psychological aspects of interface design: the perception of speed is almost entirely subjective. Huge pages that manage to present a small amount of content early in the loading process will "feel" faster than a smaller page that must fully load before it can be displayed.

Adding dimension attributes to my pages is a pain. Is there an easier way?

Of course! I'm the first to agree that extracting image sizes and adding them to every <img> tag on your page is tedious and error-prone. I'm also adamant that you use them wherever possible to reduce page rendering time. Finally, I hate spending a lot of time tweaking my <img> tags every time I change an image.

Fortunately, a kind reader pointed me to gifsize, a nifty tool that reads your HTML documents, finds all the <img> tags, locates the referenced image, and inserts the appropriate height and width attributes back into the <img> tag. What more could you want?

Gifsize is a Perl program that should run on any computer sporting Perl. It has a few options you'll need to set before running it the first time, but even inexperienced users should have gifsize doing something productive in short order. Gifsize is perfect for processing documents that use images stored directly on your system.

If you find gifsize hard to use or lacking in some way, try WWWis instead. Based upon gifsize, WWWis fixes many of the shortcomings of gifsize and goes on to offer several other nice features, including the ability to download images from another server. Again, you'll need the ability to run Perl on your computer, and WWWis has even more user-level options than gifsize. Still, the net result is worth a bit of your time to configure the tool, and visitors to your site will be eternally grateful for your snappier page loading times.

Image widths, one more time

A few months ago I offered the tip that images could be made to stretch across your documents to exactly match the browser window size by adding width=100% to your <img> tags. This little trick worked great, except that several readers discovered that it did not work when the image was contained in some other HTML container, especially a table cell. In these cases the browser just ignored the image.

By sheer chance, a reader happened to discover that percentage image widths do work in table cells if the cell happens to contain a horizontal rule. Even better, the rule need not be in the same cell; placing it in another cell in the same column seems to work just as well. Clearly, this is a browser bug, but if you simply must have images stretch to fill a table cell, and you can tolerate a horizontal rule somewhere in the same column, this little trick might just save the day.

Save my day...

You can save my day by writing with your questions, tips, tricks, and hacks. The give and take between readers and myself is what makes this column work. Be a part of it: take time to write and enrich the experience for all of us.

Resources

A list of Chuck Musciano's HTML Q&A columns in NetscapeWorld http://www.netscapeworld.com/common/nw.backissues.column.html#html
WWWis http://www.tardis.ed.ac.uk/~ark/wwwis/
gifsize http://www.ugcs.caltech.edu/~werdna/gifsize/ Perl home page http://www.perl.com/perl/index.html
" HTML 3.2 explained and demonstrated", an ongoing feature story in NetscapeWorld. http://www.netscapeworld.com/netscapeworld/common/nw.tags.html
HTML Guru, columnist Chuck Musciano's Web server http://members.aol.com/htmlguru/
HTML: The Definitive Guide http://www.ora.com/www/item/html.html
A list of Chuck Musciano's Webmaster columns in SunWorld Online. SunWorld Online is produced by NetscapeWorld's publisher.

About the author
Chuck Musciano has been running Melmac and the HTML Guru Home Page since early 1994, serving up HTML tips and tricks to hundreds of thousands of visitors each month. He's been a beta-tester and contributor to the NCSA httpd project and speaks regularly on the Internet, World Wide Web, and related topics. His book, HTML: The Definitive Guide, is currently available from O'Reilly and Associates. Reach him at chuck.musciano@netscapeworld.com.

You can learn more about and buy HTML: The Definitive Guide (Second edition) at Amazon.com Books.

HYIP Monitor