Tables in design

Tables are often used in the design of pages, often with better luck than the use of frames. But even if tables seems easy to work with, there are still traps to fall in if you're not careful. Here I will only touch some aspects on the use of tables.

(Design with one table) Imagine you use one table to get a design like the illustration to the right here, using colspan as appropriate. It works nice, but maybe you would like something more advanced, that you need to use more tables for. You may have a table inside a cell, but maybe there's a better way to do things? If you have everything inside one table, then many browsers will wait until verything is loaded before the page is shown. If you have a quick-loading page, probably without lot of pictures, this may not be such a big problem. It's worse if there's much to render (show) on the page, in that case a solution with several tables may be preferred.
This illustration shows a way to achieve the same design with tables, and it means that you don't have to wait until everything is loaded before something is shown. The first table at the top will show its content while the rest is being loaded, keeping the interest of the visitor. There is also a trap to go in, if you're not careful.

With the first design using one table, you may want to set the width to 95%, and set the width of cell 2 to say, 125 pixels. This may give a neat, good looking design no matter what the size of the browser-window. Do you want to try the same trick with the tables? Let's see what happens if we use a browser-window 1000 pixels wide (for the sake of easy numbers.)

You set the width of table 1 to 95% - this translates to 950 pixels in our example. Table 2 should be 150 pixels wide, and so we set table 3 to 80% - 800 pixels. 150 + 800 = 950, the same width as table 1, and it's looking nice. The last table is the same size as the first. All in all, a successful design. That is - with a 1000 pixels wide window, but what happens if we have half the size?

95% of 500 pixels equals 475 pixels. This is the width of table 1 and 4. Table 2 is still 150 pixels wide, which leaves 350 pixels next to it. If the browser use the window-width to calculate its 80% space, it arrives at 400 pixels, but that leaves us with too little space in the window; 150 + 400 pixels is 550 - 50 pixels wider than the window. We may have to scroll sideways. If the browser use the reminding place, 350 pixels, to calculate the width of the table we get 80% of 350 = 280. 150 + 280 = 430 - this is considerably less than the tables at the top or bottom. (In the latter case, the numbers for the 1000 pixel wide window must be corrected, but it gives similar results.)

(Table design with unexpected results) You get similar behaviour if the browserwindow is wider than in the original design, with the tables getting wider and therefore shorter than intended. Difference in font-settings etc. for various visitors may also give unexpected results. If table 3 is shorter than table 2, then the bottom table may be placed next to it as shown in the figure to the right. This may be remedied with a simple <br clear="all"> after table 3, but one thing it does show is that tables may not be simple to use in design always.

How should we avoid the problems? What is shown over is the result of mixing percent and pixel widths, and this gives variable results depending on the size of the browserwindow. The logical conclusion would be to either use only pixel sizes, or only percent sizes - but this may not produce the wanted results after all: If you use pixel sizes, the design won't adapt to the window-width. If you have a larger window than the designer of the pages, you will get large, empty spaces. Similar with smaller window than the designer, then you have to scroll sideways to read. This is very annoying, and therefore often considered a big "no-no" in design (especially among those who know the possibilities and limitations of web-based publishing.)

(Table design limited withing the bounderies of
      one table) A pure percent-based design will adapt to the browser window, but may yeld unwanted results: One table may become too wide for the content to be presented neatly, or too narrow for the content to be read easily. A combination of percent and pixel sized tables should be possible, but how should it be done?

If you put the whole design within one table with one single cell, you may not set the width for all the tables inside it, just let them fill out the space within the boundaries of the surrounding table. That way you may mix percent and pixels without worrying about the right edge of the design, but there's one problem: It's very like the first example, with one table and many cells, each which may contain another table. And like that example, everything has to be loaded before you can see anything on the screen (in many browsers.) What you gained by using many different tables are therefore lost again just as quick.

(Table design with selected tables inside
      one bigger table.) All is not lost, however. The problem (usually) arises when there are tables aligned next to each other, so why not combine tables with this in mind? Table 1 poses no problem, as it is by itself on the top. Table 2 and 3 are next to each other, so we put this inside another table which has the same with in percent as table 1. Table 2 has its width specified in pixels, and table 3 occupy the rst of the space inside it. At the bottom table 4 has it's place nicely.

With this approach, the content in table 1 can be shown while table 2 and 3 is being loaded. When these two are being shown, tha last table are loaded and rendered. As you're showing parts of the page faster, chances that visitors wait a bit more and read your pages increases, as they get something to see/read while waiting for the rest of the page to load. To further help the speed, it is very important to specify width and height of pictures.

Be the first to write a comment


Write comment

The only HTML accepted is <strong> and <em> - all other tags are stripped from the comment.


Title of comment: