Benefit from frames without getting any pains

Jake Howlett, 3 April 2001

Category: Miscellaneous; Keywords: overflow css span view cell

Without wanting to get in to any arguments I'm going to come out and say that I think framesets are the work of the devil.

Ok, so they have their good points, but, from a design/usability perspective, they are an absolute nightmare. Wait. Don't stop reading. This article is not going to get in to a lengthy discussion of their pros and cons. What it is going to do is suggest an alternate solution to the problem (for which frames always seem the logical answer), that has none of the nasty side effects. This tip could possibly change the way you develop websites. Forever!

One of the moans I get the most from users when talking to them about a non-framed site is usually along the lines of:

when I scroll down the page the navigation bar dissapears!

The answer I always wish I could give is along the lines of "well why not just scroll back up the page?!". Being a nice guy I usually succomb to their wishes and end up using frames. No need to anymore - not now that a very nice man called Chip Dashiell from the US has let me in on a neat little trick to create scrolling table cells. Yes scrolling table cells. Look at the screen-shot below. Look like a frameset to you? Well, it's not. Not even an <iframe> nor a layer.

Assuming you are using Internet Explorer the table below should demonstrate the principle.

Appointments View for Jake Howlett

By Name
By Date
Next Week
Next Month

Monday - Go to work
Tuesday - Go to work
Wednesday - Go to work
Thursday - Go to work
Friday - Go to work
Saturday - Go Crazy
Sunday - Recover
Monday - Go to work
Tuesday - Go to work
Wednesday - Go to work
Thursday - Go to work
Friday - Go to work
Saturday - Go Crazy
Sunday - Recover
Monday - Go to work
Tuesday - Go to work
Wednesday - Go to work
Thursday - Go to work
Friday - Go to work
Saturday - Go Crazy
Sunday - Recover

So, how does it work?

Well, in three words - Cascading Style Sheets. The W3C's CSS Level 1 Standard defines the overflow attribute. This tells the browser what to do if an element doesn't have enough room to disply all its content. In the case of the cell in the table above it contains a <span> which has overflow set to "auto" and hence shows scroll-bars whenever they are required. Notice in the HTML code below that the span has its width and height set to 100%. This makes it occupy the whole of its containing element which, in this case, is the cell. Because this cell has its height set to 130 pixels the content is caused to scroll.

The HTML for the scrolling cell in the above table is:

<td height="130">
<span style="height:100%;width=100%;overflow:auto">
lots of content here!
</span>
</td>

How can we use this in Notes?

Let's take a common example. The view. More precisely the view template or $$ViewTemplateDefault. Most of the page is often made up of common elements such as the header with the logos and title, the navigation area with links to other views and the main content of the apge - the view. This is what I've tried to mimick in the table above. Scrolling in this case is caused by the view containing lots of entries. Using the above solution and placing the view inside a span inside fixed-sized cell lets the user scroll through the content of the view whilst the naviagtion remains in place. No framesets either!

On your $$ViewTemplate form start the table with the following Passthru HTML:

<table height="150" width="350" cellpadding="0" cellspacing="0" border="1">
<tr valign="top">
<td colspan="2" bgcolor="#ffcc00" width="200">

On the next line, place some computed text that uses the @ViewTitle @Formula to display the name of the view or simply type the name straight on the form. Now add the next two lines of Passthru-HTML, ending the cell and first row and starting the navigation cell.

</td></tr>
<td bgcolor="#ffcc00" width="100">

After these lines is where you put all the navigation links and hotspots and stuff. The next three lines of Passthru-HTML end the navigation cell and start the main cell where the scolling is going to happen.

</td>
<td valign="top" height="130" bgcolor="#ffffff">
<span style="height:100%;width=100%;overflow:auto">

This is where you would put the embedded view or a $$ViewBody field or, if it were a form rather than a view, the fields and buttons. All that is left to do then is complete the table using the following Passthru-HTML:

</span>
</td></tr></table>

In the Domino Designer the form should be looking something like the form below. Notice in this screen-shot that the table has been set up to take up the whole screen (100% x 100%) and, in this case, the scroll-bars only appear as and when needed:

Have a look at this example of a page where the scroll-bar is only required depending on screen resolution.

Summary

So there you have it. You can have the best of both worlds now. The user never has to lose site of their navigation and you never have to lose sleep over all those frames you wish you'd never started using.

Some of you may still be thinking that framesets are good because it saves the navigation and header pages having to reload every time. Well, if you read this far, I assume you develop only for IE. If so then probably for an Intranet. If so then no need to worry about time or bandwidth!

Other reading:

W3C's Documentation on the Overflow attribute

Note: It was brought to my attention (thanks Rk) that this doesn't work so well when being printed. After a little jiggery-pokery I came up with a solution. Take a look at this version of the above example that you can print. It uses a method discussed here.