[jayeff]

Originally Posted by Lemmy

I do that too, keeps things nice and tight. I hate it when I see pages disintegrate at higher screen resolutions.

The visible difference in loading speed when talking about a typical gallery page is very small: for broadband connections, practically none. But poor coding is poor coding and most webmasters are likely to code other - bigger - pages at some point, continuing to use the coding style with which they are familiar.

As soon as a browser encounters a table, it has to read to the end of the table before it can display any of it. The longer the table is and the more poorly coded, the longer it takes. When you see sites which initially show an empty page and then after a pause, the whole page displays at once, you can about guarantee you are looking at a page with everything enclosed in a single large table.

From the performance point of view in this context, there are degrees of poor coding. The worst is when only the main holder is given a dimension, so browsers not only have to read to the end of the code, but then calculate the layout.

That is the tempting way to go because it saves time when creating the page. It is also easier, if you want to change anything later, than having to change lots of width declarations. Hence its popularity. But at least if you do declare all the cell widths, you spare browsers the need to make calculations and that speeds the display up.

If you must use tables at all, then declare the CSS property table-width:fixed; whenever possible. If you combine this with dimensions for at least the first row of cells, browsers can begin displaying the table immediately and the performance difference is astonishing. Cynical? Then mock up a huge table containing lots of rows of text, stick it on your server and watch it hang then pop. Add table-width:fixed and you will see how the content begins to display immediately. Smaller tables, smaller benefits, but they still exist.

There are - as this page demonstrates - display differences between this property and the default (auto) handling, of which you need to be aware.

I'm unashamedly gung-ho for table-less design for several reasons. I can bang a 1-inch nail into a piece of wood using a 20lb hammer, but that marks me out as an amateur and I take pride in my work. More practically, pages coded with correct, modern code load faster, work better with the search engines, are more future proofed and (yes, despite the few incompatibilities) more cross-browser compliant. If you think all tables display the same way in every browser, you are wrong.

I can take the exact same HTML and by changing a single file, totally change the way my pages look. That is a huge time-saver when it comes to making galleries, TGP's, blogs, etc, repeats of structurally similar pages/sites that I want to look different. That should also suggest how much easier site maintenance becomes when you want or need to make changes in future, particularly if for some reason you cannot change the HTML.

Finally, there are many things I can do with CSS which are simply not available any other way.

Sure there is a learning curve, just as when learning HTML in the first place. But this is business and it moves on. You invest in yourself or get left behind. On a purely pragmatic level, if you don't learn CSS I guarantee that in a single year, you lose more time via poor productivity, than learning CSS would have taken.