Forum Moderators: open
I very much prefer to build complex tables than just keep using a new one all over the place.
I tend to use 2. One for the page layout and then one nested in the content cell for the content. It makes it very easy to maintain the two main elements of the page individually. I find this method the easiest to maintain so one small change doesn't require me to alter many tables.
One of the tricks is to use THead, TFoot and TBody tags, for the corresponding sections. I always specify widths in either exact or percentage values, rather than leaving them to chance. If the master table's first row of cells stays the same down the page, and you specify the widths in each first row cell, the entire table can be drawn in one layout pass, then the content is filled in. There is a css code called "layout-table" that can be used to assist tabular layouts for cross-browser compatability. I still do not trust all browsers to display three column, three row layouts using only css rules, but I do trust them to display my tables correctly.
Wiz
When parts of a page are connected in meaning, and therefore visually related, I also want them to be "close" to each other in the HTML document as well. Keyword proximity matters a lot in multi-keyword searches and nesting tables or complex cell arrangements can really play havoc with that factor.
Messed with my head something terrible, however thanks to some of her examples (taken with credits back) I’m NEARLY a convert just awaiting the test results, back stay tuned.
I know I’ve sinned please forgive me ;)
Rich
Hybrid Tables/CSS used here..congratulations you have completed step 1.. and have been accepted into the program!
Richard you are almost a graduate.. :)
Suzy
seriously though.. the shallower the nests the better, I'd split them where possible, especially the main layout table.. if I used them that is ;)
By Wiz, a Tables Addict in CSS Rehab.
Definitely a table user here. My nests aren't even shallow (that sounds wierd). I have tables all over the place. I CAN'T STOP!
but seriously, I don't like splitting cells and doing rowspans/colspans because it seems that I lose control over the cells AROUND the split cell. I'm not sure if that makes sense. That's what I've experienced anyway.
For example, suppose I have a side-by-side comparison table of several products. The fourth row is a comparison of fees. Green widgets are charged on a sliding scale based on three levels of volume, whereas red widgets have two levels and blue widgets are a flat fee. I will create a small table (say, 2×4) for the green and red widget fees and nest them inside the appropriate cells of the larger table.
The marginal cost of overhead to create the inner tables is certainly exceeded by the marginal benefit of easy maintenance (eliminating the need to rowspan and colspan dozens of other cells), and besides I think it is more correct-- the varying fees are not part of the larger scenario posed by the main table (i.e. how are these three products alike and different), but part of a scenario within one subset of the main table (i.e. what are the applicable fees when >10,000 units are delivered vice 1,000-9,999?).
To answer your question David, yes multiple tables nested for navigation and rollover, nested for dynamic content… you name it. And as has been pointed out it works wonderfully, e.g. no complaints.
We are tested CSS only layouts at the moment but it will probably be at least 3 months before moving over and then I need to see stats for myself before taking the plunge.
I guess it’s what you get used to, it took 4 hours to produce a page using CSS only as opposed to 20 minutes using nested tables!
Rich
but seriously if it's tabular data, like you're saying, then use tables.. "nesting tables" i.e. putting a smaller table/s inside a larger table should not hinder performance in itself.
The performance of the page is dependant on the time it takes for the overall largest table to render, which is what I meant when I said to keep it as shallow as possible..
e.g. if the table is getting quite large so you notice a delay in page performance one solution would be that instead of nesting a table inside the "fourth row". Don't have a fourth row, just make your new table, even if it is only one row, and sit it under the main table.. still no need for colspans and the first part of the data will render quicker without the need for the "last row" which will render when the first bit is complete so at least the page is getting some content for the viewer.
Although this is not ususally an issue unless the main table is very big, i.e. especially where an entire page layout is lots of nested tables within 1 x large main layout table. I wasn't presuming you were talking about main layouts btw, I was using it as an example ;)
Suzy
you have completed step 1
well considering that all of the tables and css were generated with php I figure my steps and yours are a little different. ;)
Tables Rule!
I don't want to have to debug css on top of php, I'll stick to php with tables and some minimal css and leave the liquid layouts and tableless such and such to suzy and nick ;)
One of my biggest priorities when coding a page is rendering speed.
Only about a 18 months ago I finally figured out that stacked tables render a lot faster than a big container table.
But since the beginning of August my CSS competency has grown from establishing font sizes and colours to positioning and styling all the page elements and I've seen my file sizes shrink tremendously and my page rendering speed increase by up to 300%.
Rendering speed is increased by three factors:
1) The combined CSS and html files contain a lot less data than the original complex-table html file.
2) Using styled divs rather than tables for positioning means that the browser doesn't have to do two or three passes over the document to make sure everything fits - it can scan the document in a single pass.
3) External css files can be cached, which speeds up rendering tremendously.
Further to this, the content to code ratio in the html document is considerably improved which makes the page more juicy as far as the search engine robots are concerned.
One of my biggest priorities when coding a page is rendering speed.
OK so far, but then what do your browser stats say? Stats are the main reason that most people don’t move over to CSS only layouts – various idiots keep using Nutscrape.
We’ve made the decision to Ban anyone who uses it as soon as the figures go below 10% but in the stats there are still NS2 lurkers = 0.72% (OK forget them) NS3 = 3.1% (humm well they can’t have any money, so bye bye) NS 4 & MS 3 = 8.95% but when you put them all together it starts to mount up – why are they still doing it? Are they masochists?
I don’t disagree with Ya but the question is when are the nutters going to wise up or is it DaveN messing with my head ;)?
OK so far, but then what do your browser stats say?
Just over 5% of my users use an older version of Netscape (pre NN6). They can still use the pages and the pages load just as quickly. Just they don't look as pretty.
A <h1>heading</h1> is still a level one heading whether the browser in question can put a black border around it and colour the background in, or if it just displays it according to the browser default stylesheet.
I don't see any need to cater specifically for NN4 users as long as my documents are well formed and usable.
I'm certainly not going to go back to nested tables now that I've seen the light.