This is something that often comes up when someone hasn't embraced semantics; Is the content tabular data? No? Then why is it in a TD...
Though I can understand where you are coming from as a lot of the "hate" on tables is 100% bullcookies -- either manufactured by those who just irrationally hate them, propagated by those who never learned there are tags other than TR and TD that can go into them, and mimicked like second rate parrots by people who don't actually understand the subject .
Even the 'it's not tabular data' arguement doesn't exactly hold up under scrutiny when one of the the American Heritage dictionary definitions of TABLE is:
An orderly arrangement of data, especially one in which the data are arranged in columns and rows in an essentially rectangular form. Columns and rows? Sounds like a website to me. So much for it being non-semantic or a 'hack'.
But let's look at some of the other 'myths'
"It's less code avoiding tables" -- no, it's only less code to not ABUSE tables slapping them around every element! You see this all the time where people nest table in a table in a table in a table for something that as a tabular layout should only need ONE table, not twenty.
Try making a content first hack-free (as in REAL hacks like * html or that markup bloating IE conditional bull) three column 100% min-height layout that's as small and clean source-wise and as bulletproof cross browser as this:
http://battletech.hopto.org/html_tut...3coltable.html
So much for smaller code.
"Tables are deprecated" -- Uhm, no... since when? Complete nonsense yet we STILL have people making this claim, which is just ignorant. They exist for tabular data - end of story.
"Tables take too long to load" -- If written properly they take no more or less bandwidth (and often take less!) then they do not take longer to load -- PERIOD! Typically the people making this claim are actually talking about rendering time, which combined with this "fastest browser" obsession being some of the biggest online idiocy of the past decade and a half... Bandwidth is still in most every case slower than the machine that's receiving it for rendering -- quite frankly if an am386/40 running the "abysmally slow" IE3 under windows 3.1 was able to render a table in a reasonable amount of time for the end user, this particular claim is 100% manure when you can get a 1ghz HANDHELD. So much for load time.
"They should be avoided at all costs" -- WHY? If you HAVE tabular data it's the right tag set to use... This has been reaching ridiculous proportions of late in forum skins (see the bloated mess that is vBull4), where we have people abusing definition lists and nested unordered lists on OBVIOUSLY TABULAR DATA... like a board index. Take this page for example:
http://forums.digitalpoint.com/forumdisplay.php?f=39
That is OBVIOUSLY tabular data - the columns are related, the rows are related -- and yet if we look at the code for what should be a CAPTION and THEAD of TH we find this idiotic train wreck:
Code:
<div id="threadlist" class="threadlist">
<form id="thread_inlinemod_form" action="inlinemod.php?forumid=39" method="post">
<h2 class="hidden">Threads in This Forum</h2>
<div>
<div class="threadlisthead table">
<div>
<span class="threadinfo">
<span class="threadtitle">
<a href="forumdisplay.php?f=39&sort=title&order=asc" rel="nofollow">Title</a> /
<a href="forumdisplay.php?f=39&sort=postusername&order=asc" rel="nofollow">Thread Starter</a>
</span>
</span>
<span class="threadstats td"><a href="forumdisplay.php?f=39&sort=replycount&order=desc" rel="nofollow">Replies</a> / <a href="forumdisplay.php?f=39&sort=views&order=desc" rel="nofollow">Views</a></span>
<span class="threadlastpost td"><a href="forumdisplay.php?f=39&sort=lastpost&order=asc" rel="nofollow">Last Post By<img class="sortarrow" src="http://b.dpstatic.com/buttons/sortarrow-white-asc.png" alt="Reverse Sort Order" border="0" /> </a></span>
</div>
</div>
Endless div for nothing, h2 for caption's job, (of text that's not even shown on the page, so that's content cloaking!), semantically neutral tags around elements that should have meanings applied to them... it's 991 bytes of whitespace stripped markup doing the job of 939 bytes of formatted table element's!
Code:
<form id="topicList" action="inlinemod.php?forumid=39" method="post">
<table>
<caption>Threads in This Forum</caption>
<thead>
<tr>
<th colspan="2">
<a href="forumdisplay.php?f=39&sort=title&order=asc" rel="nofollow">Title</a> /
<a href="forumdisplay.php?f=39&sort=postusername&order=asc" rel="nofollow">Thread Starter</a>
</th>
<th class="replies">
<a href="forumdisplay.php?f=39&sort=replycount&order=desc" rel="nofollow">Replies</a>
</th>
<th class="views">
<a href="forumdisplay.php?f=39&sort=views&order=desc" rel="nofollow">Views</a>
</th>
<th class="lastPost">
<a href="forumdisplay.php?f=39&sort=lastpost&order=asc" rel="nofollow">
Last Post By
<img src="http://b.dpstatic.com/buttons/sortarrow-white-asc.png"
alt="Reverse Sort Order"
/>
</a>
</th>
</tr>
</thead>
It gets worse when you get to the actual entries where it abuses OL, UL, and stuffs it full of 'hidden' text for javascripted garbage. "Oh but the scripting enhances the user experience and not using tables makes it more accessibile" -- yeah, turn CSS off and say that. (I particularly like how the javascript is thrown into an endless loop when CSS is disabled in Opera). It's hardly surprising that it ends up an unbelievable 242k of markup to deliver 6k of visible content and 20k total content -- proof of ineptitude of the highest magnitude. It's no wonder Sitepoint still hasn't upgraded to vBull 4 -- four is such a disaster I'd not be surprised for them to be giving SMF or phpBB a serious look instead! They got balls o' thunder charging $200 a pop for that rubbish!)
Really the problem with tables for layout was NEVER actually the use of tables for layout itself no matter what some people say. The problem was people continuing to use fat bloated rubbish markup in building their tables, nesting them endlessly for no fathomable reason and not using ALL the tags available to us. A great example of this I use a good deal is this example -- which you'll see people do all the blasted time:
Code:
<table cellspacing="0" cellpadding="0" border="0" class="myTable">
<tr>
<td colspan="4" class="bigTitle"><b>Table Title</b></td>
</tr><tr>
<td> </td>
<td class="heading"><b>Col 1</b></td>
<td class="heading"><b>Col 2</b></td>
<td class="heading"><b>Col 3</b></td>
</tr><tr>
<td class="rowHeading"><b>Row 1</b></td>
<td class="rowData">Data 1-1</td>
<td class="rowData">Data 1-2</td>
<td class="rowData">Data 1-3</td>
</tr><tr>
<td class="rowHeading"><b>Row 2</b></td>
<td class="rowData">Data 2-1</td>
<td class="rowData">Data 2-2</td>
<td class="rowData">Data 2-3</td>
</tr><tr>
<td class="rowHeading"><b>Row 3</b></td>
<td class="rowData">Data 3-1</td>
<td class="rowData">Data 3-2</td>
<td class="rowData">Data 3-3</td>
</tr>
</table>
Unneccessary attributes on the TABLE -- COLSPAN, CLASS and B doing CAPTION's job -- class="heading" and B doing TH's job,   doing empty-cells:show; 's job, .rowheading and .rowdata doing TBODY, TH and TD's job. There's ZERO excuse for the markup to do that same job to be more than:
Code:
<table cellspacing="4" class="myTable">
<caption>Table Title</caption>
<thead>
<tr>
<td></td>
<th>Col 1</th>
<th>Col 2</th>
<th>Col 3</th>
</tr>
</thead>
<tbody>
<tr>
<th>Row1</th>
<td>Data 1-1</td>
<td>Data 1-2</td>
<td>Data 1-3</td>
</tr>
<tr>
<th>Row2</th>
<td>Data 2-1</td>
<td>Data 2-2</td>
<td>Data 2-3</td>
</tr>
<tr>
<th>Row3</th>
<td>Data 3-1</td>
<td>Data 3-2</td>
<td>Data 3-3</td>
</tr>
</tbody>
</table>
Which provides JUST as many CSS hooks for styling thanks to the use of *SHOCK* semantic markup... and it's a 40% reduction in code.
Bottom line, tables exist for a reason, so use them when you have good reason to. The key is NOT to use them when they are unneccessary... As I've said a dozen times:
When to use a table:
1) When the rows and columns are related, and typically have headings that apply to the ENTIRE row and/or column. Again, forum indexes come to mind where you have obvious fields of data, each row all the same type of data inside a row, each column being information for a record.
2) When the faux-column effect just won't cut it.
3) When you require RELIABLE vertical positioning of dynamic height content in a fixed height or sibling related height element.
When NOT to use a table:
1) When the content is unrelated elements that should not be semantically grouped.
2) When you would only have one column or worse, just one TD inside the TABLE
3) When you do not want rows and columns when CSS is disabled.
There's plenty of good reasons to not use tables for layout, we don't need to be making up fictional excuses... There are plenty of good reasons to USE tables such as when the data is *SHOCK* tabular, so this "don't use tables at any cost" mentality of abusing things like definition lists and ordered lists in a NON-SEMANTIC manner is some of the biggest idiocy this side of the White House lawn.
But of course when people are still doing garbage like clearfix, spacer.gif's and px metric fonts on content, you really can't expect them to do anything properly.
Originally Posted by agrable
still they will runing into many problem. as i work on a project wich has large tabular forms.95% is controlled by css (everything expect tables) and just 5 % r of tables. and its a massive app for like 5000 pages. i love semnatic markup and css 
Bookmarks