Welcome to WebmasterWorld Guest from 126.96.36.199
Forum Moderators: incrediBILL
The original idea was simply to allow data to be displayed in rows and columns -- a logical structure, and not intended for page layout purposes. But designers jumped on it and soon an overwhelming majority of sites were laid out with tables.
The key to using tables for layout is in appreciating that we are using a tool that was not designed for the job. There simply will be frustrations, especially cross-browser.
1) One frustration is the way Netscape, up to 4.7, deals with spaces, tabs, and line-breaks (hard returns) within the code itself. Sometimes, but not very predictably, the browser adds extra space to the table cell. If your HTML validates, and the page looks great in MSIE, but Netscape won't match up elements properly, try eliminating all the spaces and hard returns between </tr><tr> and </td><td>.
2) Another issue comes from bad code. TABLE, TR and TD tags should come in pairs and always nest logically. MSIE often can forgive bad code, but Netscape more often simply refuses to render anything in the offending table.
3) Then there's rendering speed. If a big page is enclosed in a single table (or intricate nested table system) the page may be slow to appear on screen, especially in Netscape. See the bottom reference link for another discussion here on WebmasterWorld about improving rendering speed when using tables for layout purposes.
4) Finally, using tables for layout is not recommended by the W3c. This practice can be very confounding to assistive technologies, such as speech-synthesized browsing. Anyone wanting to declare level "double A conformance" [w3.org] to the W3C Accessibility Standards -- stay away from layout tables and control the layout with CSS.
Any other table issues people have uncovered?
W3C Spec For Tables In HTML 4.0
W3C - Tables And Accessibility
White Space Bug Discussion
White Space Bug Reference
Rendering Speed Discussion
I use tables everywhere - a grand abuser of the scheme. They are getting old, but you just can't beat them for controlling layout.
One of the interesting tags in html4 is the tfoot, thead, and tbody tags. If you are using html4, they might be well worth a look because the added functionality.
What I would like to find, is a HTML validator, (other than cse) that can successfully find table problems.
For complex tables, with many cells that have a column or row span of more than 1 (very prone to strange spacing errors), I make sure ALL cells have a height and width attribute specified, and I add a row of 1px cells across the top, and a column of 1px wide cells down one side... then in each 1px cell, I place a transparent gif that exactly matches the height/width of the row/column it belongs to.
Don't know why, but it seems to cure the syndrome of one cell or another displaying at a really randomly huge width or height.
The touchy part is declaring table width AND the cell widths. The table width amount must account for the total of individual cells PLUS cellspacing and cellpadding (which are 1 pixel by default) or anomalies will show up.
Here's a page [iglou.com] that really disects the cell width problems in tables. I found that one good study of the concepts here helped me a lot.
Edited by: tedster
As for the cell width/teble width settings: in GoLive, you can leave the table width setting on "auto", define all your cell widths, and then use a drop down selector to change the table width setting to "pixels". It automatically calculates the pixel value for the table...
"no math required" is always a bonus feature to me! ;)
The first is use a client side image map -- but spiders don't usually follow image map links (not sure about googlebot -- it seems to eat almost everything these days).
Second, slice up the GIF and then link the relevant portions as a straight HTML link. A little more work, but the spiders will appreciate it.
This has the advantage of not pushing the links a level "down" into a nested table structure. Spiders seem to like content that isn't nested.
NOTE:As we discussed in another thread [webmasterworld.com], this will wreak havoc with the Google cache display.
When it comes to optimization concerns for this graphic table, name your image slices well, use the alt text in each image, and name your link destination pages with your keyword strategy in mind -- all this helps.
I just re-read your post and see that I misunderstood what you were saying. So, only some of what I said really applies to your particular goals.
Tables are the great tool, but new designers do not understand them completely and abuse the whole idea badly sometimes, unfortunately.