Forum Moderators: open
1) Pushes down visible content, wastes space in the top of the code, which may be all the spiders are interested in.
2) Decreases visibility ratio
I'm curious if these are both accepted as fact, if there are other reasons, and just how important the community finds these issues to be. In particular, I'm curious if it's generally worth it to restructure an existing website using CSS instead of nested tables, or if it's a small enough detail that it can be tabled until the next redesign.
Thanks in advance for any insight you can offer
T
Nested tables should not impact SEO effforts as long as they validate and there is a sensible amount of nesting.
Now, you can also break these semantic connections with absolutely positioned divs, but the problem is a lot less frequent or likely with a CSS-P layout.
1) Structure them so that a reader parses the table in a logical order(reader being software that reads the page aloud to the viewer, who may be blind.) Ordinarily this is begins at the top row, reads across the cells (td's) then moves to the next row. If you use the table tricks to push content to the top that ordinarily wouldn't appear at the top for SEO purposes, this will most likely fail a 503 review.
2) Use the summary attribute for all tables (<table summary="layout table"> )
3) Don't nest tables within tables. If a situation arises where you actually have to use tablular data, you will have to rethink the page layout so that the table exists within divs, using CSS to control the presentation.
There are many more 503 accessibility guidelines - the most common violations being table usage and the absence of the alt tag for images - but the biggest hurdle for a the table-layout handicapped webmaster is figuring to how to avoid nested tables.
Now, in my experience there is never a need for nesting a table. Thou it takes some doing and it fairly cracks the brain at some stage, I have found it is ALWAYS possible to do with a simple table what has been done with nesting.
Whether nesting has an impact on se's is arguable but that it slows down load-times is not a question. Not only is it more code but it also adds the equivalent of a 'loop' to the program, for those familiar with the term.
Another way to say it is, a browser HAS to read the entire table before it can render any part of it, meaning nothing shows until everything has been processed. With a simple table things are slow enough at times, but with a nested table the browser first has to read and process the inner-most table then work its way outwards and only by the time it has finished the outer-most table is it ready for display.
For an example of what I mean by simple tables, my home page is all ONE table, it is a matter of colspan and rowspan and thinking about it for a bit.
[edited by: tedster at 11:37 pm (utc) on Dec. 4, 2005]
it is a matter of colspan and rowspan and thinking about it for a bit.
Agreed -- I once spent an entire afternoon experimenting with tables and their attributes. By dinner, I understood all kinds of things in a new way. Fortunately, basic table cells and their attributes are consistent cross--browser. For this reason alone, I reverted to a basic table for layout after I created 5 pure-CSS layout websites.
Now, within the table, I do not nest tables -- I use CSS all the way and I write validated and strict html or xhtml. But the basic "framework" for the page is a table layout. You see, I do not re-use page templates from client to client, and so each website is a customized development. Today's browser chaos in CSS-P makes pure CSS development too time consuming for customized production work, IMO, and I don't want to be leaving an obvious footprint on everything I develop by re-using a proven template.
However, I love the idea of pure CSS and certainly hope the future makes the approach more practical. I understand that layout tables are essentially a "hack" -- but just look at all the many hacks required to get a CSS layout happening!
