Turning the tables
Tableless layouts have become something of a holy grail for forward-thinking Web designers. It's almost as if the use of tables has been totally banned or deprecated by the W3C – they haven't! Table-based layouts can still validate 100%.
Tables are still used for layout purposes in most sites these days but undoubtedly, there is a definite movement towards using Cascading Style Sheets for layout instead – after all, that's what CSS is for. Tables have some disadvantages though, especially when abused or multiply nested.
From a bandwidth point-of-view, the markup required to make a table is less efficient with lots of s and s, even when the cells are empty.
What seems like a fairly logical text flow on the screen becomes disjointed and hard to follow when you look at the source code. This makes manual editing more difficult and causes problems with screen-reading software for the visually impaired.
CSS has many more facilities and possibilities that tables just don't allow - it's easier to break out of strict grids, you can overlay text upon graphics and play all kinds of tricks with the background images.
The capabilities of tables have been eroded over the years. Although you can still set the height attribute of a table or cell and it will work in some browsers as it used to, modern browsers are stricter and are beginning to reject these deprecated features - and they certainly won't pass HTML 4.01 validation.
But with CSS, all is not sweetness and light. Tables have certain advantages too that must be considered.
Table-based layouts work in even the oldest browsers with a high degree of predictability.
The various page editors display them correctly and make the contents easy to edit.
CSS has no equivalents of valign='middle' or valign='bottom' which makes certain types of layouts very difficult - like when you want columns of text to align at their bases instead of at the top.
As I hinted in the introduction, turning this page into a tableless, CSS-P layout was quite a major task. What would work fine in Netscape 7/Mozilla 1.2 to W3C CSS specifications fell over completely in Explorer. Getting it to work in both was the tricky part. Explorer does some strange things – the way it handles nested boxes (divs), float and clear, padding and, most importantly, relative position, means that you need to use some pretty convoluted workarounds.
Adobe GoLive, which I normally use, is great for table-based layouts and for editing CSS definitions but totally useless when editing a CSS-P layout. It makes no attempt at showing the layout whatsoever in either edit or preview mode, placing divs one below the other regardless. It really is time that Adobe sorted this out for their flagship web page editor.
Dreamweaver MX makes a more creditable attempt but still doesn't agree with Explorer or Mozilla as to how the page will look. I know that the guys at Macromedia are working on this but for the moment, just like clocks and watches, being 'nearly right' is actually more confusing and potentially dangerous than being totally wrong.
Netscape's freebie Composer gives by far the best editing environment for CSS-P layouts, but is lacking in certain other important areas and isn't something I'd want to use as a main tool.
So, as I always do in such cases, I go back to my old trusty BBEdit and use the actual browsers to preview the results.
Although this article is about converting table-based layouts into CSS ones, a literal one-to-one conversion is fairly pointless if you don't use some of the benefits of CSS-P. Nevertheless, I have tried to keep the general grid that I used before. For the purposes of this exercise, it is better to compare like with like. After all, this is an evolutionary update not a total redesign. I will use those extra capabilities of CSS as the occasion demands.
The page starts with a body definition that includes the new, paler page background image and margin definitions. As I mentioned earlier, I believe that it is important to keep some visual link with the older one.
Within the body is a box called #page, which is 700 pixels wide and centred on the browser window.
Inside #page is a box called #inner that provides the container for the main content – it is 652 pixels wide. I use this to avoid having to use 'padding' and its inconsistent implementation in Explorer.
The basic grid is made from three box classes called .col1, col2 and col3 and roughly equate to the table columns of the original page layout. All are set to float left and if left to their own devices within the constraining #inner box, would provide what is essentially a grid similar to a table.
1 2 3
1 2 3
1 2 3
In the old tabled layout, sometimes columns one and two were joined with colspan="2" to give more space, so a similar option is also provided with a box called 'col12' – which is simply the sum of the widths of col1 and col2, including col2's right margin of 12px.
This simple nested boxes principle works completely as expected in Netscape/Mozilla. The two main boxes #page and #inner stretch vertically to encompass any number of 'rows' of col1, col2 and col3. Not so in Explorer though! In Explorer, they don't expand to encompass the rows as expected and no amount of juggling the float and clear properties of the cols produced anything other than frustration.
The workaround was to create a new horizontal spacer box class called .horzspace which has its 'clear' property set to 'right' and which spans the full width of the inner box.
In simple, diagrammatic terms, it works like this. It may not be the only solution, but it's the most reliable one I've found.
Looking closer at the 'col' boxes, col1 one is straightforward and is always 45 pixels wide as it only ever contains the vertical section heading images.
Col2 should be 255 pixels wide but I didn't want to use padding so I made it 243 pixels wide plus 12 pixels right margin - this works predictably in all browsers. The text align is set to 'right'.
Col3 is 350 pixels wide and has a left border – a one-pixel rule. If I could depend on padding-left: 12px; all would be simple but Explorer puts padding in the wrong place so I have used an nested box called .textcol which has a 12 pixel left margin and its width is left unspecified. It's constrained by the 'col3' box containing it. In this instance, a 12px left padding would also work because 'col3' determines the overall width of 'textcol'.
The tableless layout works in Explorer 5 (Mac and PC) and 6 (PC), in Netscape 7/Mozilla 1.x (Mac and PC). It also works in Opera 7 (PC), Opera 5 (MacOS), Safari (OSX) and Camino 0.7 (OSX). It doesn't render correctly in OmniWeb 4.2 or iCab (OSX), but is readable. It's a total disaster in Netscape 4.x but frankly, if you still use that browser, this article probably won't be of much interest to you anyway.
On the upside, it gives me that fuzzy, warm feeling you get from producing modern, valid Web pages. On the downside, it is more difficult to edit and takes considerably more time to produce. In commercial terms, time is money and maximum reliability is a very important factor too. So, I've done it. I've proved to myself that it is possible. What happens next month is anyone's guess at this stage!