Tables or Div?
Table Problems
The <table> tag is a fairly mature, stable HTML tag. Tables are very consistent cross browser in their rendering. It is only when you begin to apply some of the newer CSS styles to them that you start getting more or less serious display problems in a cross-browser environment.
However, when you start getting into more complex page construction, the problems with tables become obvious: all table cells relate to all other table cells in the table directly. If you remove one cell from a web page table, the entire webpage collapses. You can only make an independent part of your page by nesting tables. Although we are fond of this technique, since it has a certain coded beauty, it's not very efficient, and leads to very complex pages, that can be hard to debug when you get display problems. This was, however, the only choice you had until recently if you wanted more complicated page layouts.
Tables and CSS
Of course, the advent of CSS 1 standards began to slowly change all that, as the older non-CSS 1 compliant browsers began to fade away. Now you could apply custom stylings to any table, any table cell, and any other element of your pages. The div tag allows you to create nested structures without having to create an entire nested table to contain it. Div tags, like table tags, nest very reliably.
As we mentioned, although CSS has given web authors much greater flexibility in general, the strictness of the W3C standards, and their unfortunately loose implemenation among the current generation of browsers ( Mozilla / Netscape, Internet Explorer, Opera, and the new Mac Safari / Konqueror browser ) have created new problems for the web. We can be safe in assuming that such problems will always be present on the web, although they will always also be in a state of being solved. The solutions, as in this case, are what will create the next generation of problems, and so on.
Specifically, neither Internet Explorer or Mozilla / Netscape treat things like table borders, or padding, the same. Internet Explorer 5.x (Windows only) does the intuitively obvious thing (but technically incorrect, according to the W3C standards), and keeps the fixed cell or table width stable, and adds the border, padding, or margin inside that. Mozilla, Safari, Opera, and all the other truely standars compliant browsers being created since around 2000, on the other hand, follow the standards explicitly, namely, they maintain the cell width and adds the border width to its outside. Obviously, this can wreak serious havock with the most carefully planned webpage. In general, if you are looking to have a very tight, stable layout, you have to avoid using border and padding styles on your table cells.
And then, to make matters worse, Microsoft fixed this bug on Internet Explorer 6.x, so now you have to treat 5 and 6 separately. There are some tricks to doing this, but it's unfortunate that we have to keep resorting to tricks and tips to create pages that follow standards that have been in place since 1996.
If, on the other hand, your pages are set to resize as percent values of the browser window width and height, tables, coupled with div division blocks, are an excellent solution. You can create very nice effects with a minimum of code, especially if you use linked external stylesheets, which you should be doing anyway.
Another problem with tables is again related to tight web page construction: tables do not keep their dimensions consistently; they are very fluid. Even if you have declared a table cell to be x number of pixels wide, if the table itself is set to be a percent size of the browser window, the cell size will often change as the table size changes. This can lead to hard to fix errors. For example, if you declare the table at height:100% most browsers, except Opera, will incorrectly allow it to expand, but Opera correctly cuts off all content that goes below the bottom of the browser window.
Conclusion
It is for this reason that if you want to make your web pages very tightly layed out, you should probably use an absolutely sized table to contain it, or an absolutely sized combination of table and div elements, which we believe is probably the safest route to take.
The main structural problem with tables is of course that they were never really intended to be a layout method for a web page, but were rather intended to contain tables of data, often from a database. An Excel spreadsheet, for example, is simply a complicated table, more or less anyway. But we have to say, an overly anal following of standards just for the sake of the fact that they are standards seems sort of sheeplike to us, well, more than sheeplike. There are still problems with basic things like aligning objects like tables. If you want the table, or whatever, to be centered, you have to do two things: declare the container of the thing you want centered as text-align:center;, to support Internet Explorer 5.x and 6 in non-standards, quirks mode. Then, for all other browsers, you declare the object itself you want centered as this: margin:0 auto;, assuming of course you want no margins top or bottom . Vertical alignment of objects is sketchy at best with CSS as currently written.
Given the extreme difficulty in producing cross-browser stable designs with pure CSS and div tags, it is in our opinion still not commercially viable to create such pages, although it is a very useful technique to use within a more stable page layout, given the simplicity of structures possible using div tags (for example, if you want a box hovering somewhere on your pages, you just position it using CSS, and there it is. To do the same with tables and cells would involve creating a complex structure, with rows and cells positioned in order to create the illusion of a floating block of information as opposed to an actual floating block of information.