Why Switch from Table to CSS layout?

Here’s one. www.katewertz.com

Why do I suddenly feel like a lamb being led to slaughter? Programmers looking at a designer’s code. Danger, Danger Will Robinson!! :lol:

(must resist open invitation) I’m a fan of DW myself - I was bummed that Adobe bought them since I thought the whole suite was far superior…

Don’t forget that presentation can mean different things to different people. You’ve got browser-based presentation, mobile-based presentation, accessability-based presentation, and even product speficic presentation (iPhone/iPad ring a bell?) . Using css to control layout allows for much more finite control over the presentation to these various platforms without forcing content changes (I’m defining content as changes to the html itself).

To an extent you’re right, but when you’re working in one media, and the client works in another your work has to be flexible enough to work that way. We had one that started their design review on a smartphone, which we weren’t prepared for (not in the specs), but since it was css based, it was easy enough to modify the display to work there.

There are other things than just purely visual. There’s mobile browsers vs non-mobile as just one example. And even if you’re not talking about visual, you have to look at your user numbers, even 1% could be a decent number. 1% of 10,000 is 100 users. And have you ever heard the old customer service saying that when a person has a bad experience, they will tell seven different people about that bad experience? So that 100 now becomes potentially 700 people who have a bad experience. And with the virability of the web, I’d venture that the old adage is way out of line - that seven is probably in the 100’s now and grows exponentially each day.

I’ll be the first to admit I still have problems with css-based work. I just recently have had two that I haven’t needed Paul to figure out what stupid thing I did which caused the issue.

But my most recent mockup work proved to me how powerful the work has been. I had a three column design I was working on. Well, the customer decided they wanted the two outer columns switched and the widths changed for each of them. That would have been a bit of work in the old table based methods because of having to track down the appropriate table columns and copying/pasting them, cursing because I missed a portion of the column (and I’m one to comment the end of a column to try and keep them together) or something and having to do it again

Well, for this project it was done five minutes later, and it would have been less time if I hadn’t fat fingered the widths. I change the floats on the two columns, adjusted the margins appropriately, then altered the margins on the middle column. And DONE! One file, no copying/pasting, very little problems. Much easier than in the past.

Talk to me about this. What is the benefit of using the validator? And please be kind to my ignorance.[/QUOTE]

That’s not too bad :slight_smile:

But 20 minutes later you could have something roughly like this.


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Untitled Document</title>
<style type="text/css">
html, body {
    margin:0;
    padding:0
}
p {
    margin:0 0 1em
}
body {
    background-color:#FFFFFF;
    background-image:url(http://www.katewertz.com/images/pageBKGD.jpg);
    margin: 0;
    padding: 0;
    font-family: Arial, Helvetica, san-serif;
}
a:link {
    color: #173E2B;
}
a:visited {
    color: #632B2C;
}
a:hover, a:focus {
    color: #632B2C;
}
a:active {
    color: #632B2C;
}
ul {
    list-style:none;
    margin:0;
    padding:0;
}
h1, h2.main {
    font-family: Arial, Helvetica, san-serif;
    font-size: 16pt;
    color: #173E2B;
    font-weight: bold;
    margin:0 0 2px;
}
h2 {
    font-family: Verdana, Trebuchet MS, Arial, Helvetica, san-serif;
    font-size: 9pt;
    line-height: 12pt;
    margin: 0;
    font-weight: normal;
    color: #173E2B;
}
h3 {
    font-size: 9pt;
    line-height: 12pt;
    color: #173E2B;
}
#NavImg-1 {
    position: relative;
    left:0px;
    top:0px;
}
#contents1 {
    position: relative;
    float:right;
    width: 485px;
    z-index: 1;
    font-size: 9pt;
    line-height: 12pt;
    color: #173E2B;
    margin-right:130px;
    display:inline;
    padding:45px 0 5px;
}
#locations1 {
    position: relative;
    margin:0 0 0 40px;
    width: 185px;
    z-index: 2;
    font-family: Trebuchet MS, Arial, Helvetica, san-serif;
    font-size: 7pt;
    line-height: 12pt;
    color: #173E2B;
    font-weight: bold;
    font-style: italic;
    text-align:center;
}
#wrap {
    width:900px;
    margin:auto;
    overflow:hidden;
}
#footer {
    height:60px;
    background:#173E2B;
    border-bottom:20px solid #003333;
    clear:both;
}
.logo, .logo em {
    width:900px;
    height:158px;
    margin:0;
    color:#fff;
    position:relative;
    overflow:hidden;
    text-align:center;
}
.logo em {
    position:absolute;
    left:0;
    top:0;
    overflow:hidden;
    background:url(http://www.katewertz.com/images/top.jpg) no-repeat 0 0;
}
.logo b {
    display:block;
    font-style:italic
}
.sideimg {
    float:left;
    margin:2px 10px 2px 2px;
    displau:inline;
}
#sidebar {
    float:left;
    width:285px;
    background:url(http://www.katewertz.com/images/side.gif) no-repeat 0 0;
}
ul#nav {
    width:285px;
    padding:39px 0 0;
    min-height:246px;
}
* html ul#nav{height:246px}
ul#nav li {
    display:inline
}
ul#nav li a, ul#nav li b {
    display:block;
    width:202px;
    height:25px;
    margin:0 0 0 37px;
    text-decoration:none;
    color:#000;
    overflow:hidden;
    position:relative;
}
ul#nav a b {
    margin:0;
    position:absolute;
    left:0;
    top:0;
}
ul#nav li a b{background:url(http://www.katewertz.com/images/side.gif) no-repeat -37px -39px;}
ul#nav li.home a b{background-position:-37px -39px;}
ul#nav li.services a b{background-position:-37px -64px;}
ul#nav li.jungian a b{background-position:-37px -89px;}
ul#nav li.qual a b{background-position:-37px -114px;}
ul#nav li.faq a b{background-position:-37px -139px;}
ul#nav li.loc a b{background-position:-37px -164px;}
ul#nav li.contact a b{background-position:-37px -189px;}
ul#nav a:hover b{border-left:1px solid red;width:200px}
.welcome {
    display:block;
    padding:20px 0 2px;
}
.sig span, .sig span b {
    width:160px;
    height:35px;
    position:relative;
    overflow:hidden;
    display:block;
}
.sig span b {
    position:absolute;
    left:0;
    top:0;
    background:#fff url(http://www.katewertz.com/images/signature.gif) no-repeat 0 0;
}
</style>
</head>
<body>
<div id="wrap">
    <h1 class="logo">Kate Wertz <b>Psychotherapy with Soul in Mind</b><em></em></h1>
    <div id="contents1">
        <h2 class="main">Holistic Psychotherapy and Counseling</h2>
        <p><img src="http://www.katewertz.com/images/katephoto2.jpg" width="100" height="168" alt="Kate Wertz" class="sideimg" ><strong class="welcome">Welcome.</strong>I am a licensed therapist offering counseling and Jungian depth psychotherapy in Jupiter, Florida. Over twenty years of experience supporting people to make positive life changes has taught me that each of us has the capacity for greater joy, satisfaction and peace of mind, even during hard times. </p>
        <p>Modern living can be stressful. In trying to keep up with life&rsquo;s demands, we can easily lose touch with our deeper selves. The result can be anxiety, stress, depression, relationship or career difficulties, addictive behavior or simply feeling overwhelmed and stuck. Therapy can help you to take charge of your life. It can help you to listen to your inner wisdom, to live more fully in the present and to make more satisfying choices. Therapy provides the opportunity to heal old hurts and to become unstuck. It can help you to create greater contentment, a more balanced life and more fulfilling relationships. And it can also provide support to explore your creative potential and find greater  meaning in life.</p>
        <p>This site contains information about my training and approach. I would be delighted to talk with you by phone (561-748-9512) about whether therapy might benefit you. </p>
        <p class="sig"><span>Kate Wertz<b></b></span> <strong>Kate Wertz, M.Ed.<br>
            Licensed Mental Health Counselor</strong></p>
        <address>
        Alhambra Plaza <br>
        Suite 203 E <br>
        725 North A1A<br>
        Jupiter, Florida 33477
        </address>
        <p>561- 748-9512<br>
            <script type="text/javascript" src="emailscript.js"></script>
        </p>
    </div>
    <div id="sidebar">
        <ul id="nav">
            <li class="home"><a href="index.htm">Home<b></b></a></li>
            <li class="services"><a href="services.htm">Services Provided<b></b></a></li>
            <li class="jungian"><a href="jungian.htm">Jungian psychotherapy<b></b></a></li>
            <li class="qual"><a href="qualifications.htm">Kate's Qualifications<b></b></a></li>
            <li class="faq"><a href="faq.htm">FAQ<b></b></a></li>
            <li class="loc"><a href="directions.htm">Location/Directions<b></b></a></li>
            <li class="contact"><a href="contact.htm">Contact<b></b></a></li>
        </ul>
        <div id="locations1">
            <p>Serving clients from<br>
                northern Palm Beach County and <br>
                Martin County, Florida <br>
                Easy access from Jupiter, <br>
                Palm Beach Gardens, Juno Beach, <br>
                North Palm Beach, Hobe Sound <br>
                and Stuart</p>
        </div>
    </div>
</div>
<div id="footer"></div>
</body>
</html>


I’ll explain later :slight_smile:

Without a question, use CSS layout. Take a look at

It uses the same HTML that produces completely different layout based on CSS. This is how I like to program… I posted this methodoly here in site point… they called me divitis or something and very strongly against the idea of doing it that way. Anyways, that site itself is the reason why I favor CSS~

Your page wasn’t too bad and you were brave to post it :slight_smile: I’ve seen much much worse and as long as you keep the tables simple and uncomplicated then you won;t run into too much trouble but it could be done just as easy (or more easily in my case) without tables.

There were a few semantic errors and silly things such as alt attributes missing which is very important if you are using an image as content.

Some brief explanations of my example:

The page is basically a 2 column layout which can be done with 2 floats for the columns and top and tailed with a header and footer. It’s a very basic structure that doesn’t need a table to contain it. The only thing with floats is remember to use a clearing mechanism (see faq on floats).

Starting at the top:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

The doctype above is a partial doctype (no uri) that will trigger quirks mode in all versions of IE which effectively means that IE8 renders as badly as IE5 does and will use the broken box model.

In the broken box model any elements that have a dimension plus padding or borders will be a different size to other browsers because the padding and borders are added inside the width in the broken box model. All other browsers will add the padding and borders to the dimension not subtract from it.

You also lose all the improvements of the modern IE browsers such as hover on elements other than anchors.

Therefore always use a full doctype such as:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">

But strict would be better:


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

In your page the fist actual content arrives after 520 characters but in my example it’s right there at the beginning where you would expect and within 30 characters of the start.


<div id="wrap">
    <h1 class="logo">Kate Wertz <b>Psychotherapy with Soul in Mind</b><em></em></h1>

The h1 uses an image replacement technique and supplies text for users who have images blocked; and text for screenreaders; and text for search engines. It’s win win all around. Your heading image would not rank at all as you omitted the alt attributes anyway.

The code you used for your footer was this:


    <table width="100%" border="0" align="center" cellpadding="0" cellspacing="0">
        <tr>
            <td height="60" align="center" valign="top" bgcolor="#173E2B"><img src="http://www.katewertz.com/images/spacer.gif" width="20" height="60" align="absmiddle"></td>
        </tr>
        <tr>
            <td height="20" align="center" bgcolor="#003333"><img src="http://www.katewertz.com/images/spacer.gif" width="20" height="20" align="absmiddle"></td>
        </tr>
    </table>

My code is this:


<div id="footer"></div>

I don’t even need to say anything about that :slight_smile:

Your navigation is an image map (again without alt attributes) and that will make it hard for screenreaders and SEO.

Juts use a list with image replacement techniques and everyone is happy. You can then create an easy rollover effect so that visual users will have a clue which item they are clicking on. At present I had to guess if I was on the link or not.

Keep the script external where possible.


<script type="text/javascript" src="emailscript.js"></script>

The html in my example is about 18% smaller which is surprising for such a small amount of code although the CSS file has grown it will not be an issue because it will be cached and is only a hit of first view unlike the html which will be seen on every page.

My example was only a rough guide and I didn’t spend a lot of time (30 minutes at most) on it so there’s probably areas that could be improved more.

Hope it gives you some idea anyway.

No, you see, better content (semantic content, w/o tables for layout) means also better presentation.

This is what you must understand: we don’t preach to you a philosophical view over the benefits of using CSS for layout.

Instead, we try to make you understand that using CSS for layout will open new doors for you to enhance the presentation part.

Double the fun :wink:

Actually I was referring to user AGENTS. That HAVE all the clues on HOW the site was constructed. Since they are the user… agents!

I see the need for another logical example. I don’t know how much you had to deal with databases before. But, assuming you can understand a spreadsheet data, you can also visualise how a simple table looks like.

Imagine you want to look for a certain info in a spreadsheet. You do what’s easy: bring up the Find or Search option. This will do just fine if you look singular info in a column. Still, up to a point. If your columns contain repeating data you may want to refine your search.

For databases systems you have a more powerful Find or Search option: SQL. With SQL we can interrogate data on multiple columns using different filters in an easy way.

But you see, even SQL cannot help you when your table data is not optimized for search. Meaning, for one thing, that data in your table it’s not properly indexed for search.

For tables with small amount of data, optimizing makes little difference. But when tables have reasonable large quantity of data, all the database system power, all the SQL language power, are helpless when dealing with a BAD CONTENT. The search will take ages, when, on the other hand, understanding and using indexes the right way, will only take milliseconds.

Think of CSS layouts as helpful as indexes.

Your table layout. Resorting to this solution, you are making useless the power user AGENTS have. You are offering them BAD CONTENT. It may not make a big difference to the user in some cases.

But there will be cases when tables layout will make your user question whether the solution you’re offering rises to its expectations. One thing you probably wouldn’t want to happen.

I don’t know if you understood properly: semantics is one thing. You can have semantics but your page still be invalid.

One other thing, that you have when using tables for layout, is that you have validations but improper semantics.

You have to cater for both.

The validator will point out some of the errors in your HTML structure. Where you have errors in the HTML then the chances are much greater that at least some of the thousands of different web browsers that exist will treat that garbage differently than the way it gets treated by other browsers and so your page will not look the same in all browsers. At least when your code passes validation you know that at least all the standard compliant browsers will treat it the same way and any differences will be due to errors in the browser rather than errors in the HTML.

There isn’t enough time to test your page in all of the thousands of different browsers that exist and so the most effective way of testing is to make sure that the HTML is valid and that it looks the way you expect in the most popular half dozen or so browsers. That way you can expect that most of the other less popular browsers should display it correctly without having to test them all.

You can find a list of a few hundred browsers at http://en.wikipedia.org/wiki/List_of_web_browsers which also has links to more pages that list even more browsers.

Yep totally agree 100%. I don’t see any point in having some u-beaut wizz-bang earth moving content if it’s difficult to read or get at. (but I would still advise against using tables for layout)

Plus you need to remember that the appearance will not be the same for all media. A web reader or braille printer will not be able to show any of the visual parts of the content. The appearance when printed will also quite likely be significantly different from the way it looks on an iphone screen.

yup, nothing turns me away from a website more quickly than poorly presented, difficult to read content on whatever media, no matter how good the content might be. I haven’t seen any content yet that I would not have been able to find elsewhere as well.

Hi Jennifer. I did some work for a client a while back. They had a site that had been coded as a dreamweaver tempate. Their original developer had moved on and they had got a freelancer in who had then edited their html directly in a text editor.

The HTML was valid but their dreamweaver templates were now broken. Their site could not now be automatically updated from within dreamweaver. It took me about a day to manually fix the templates.

For me, there are sometimes huge advantages to doing things the same way that everyone else does them.

That said, sometimes everyone else is wrong :slight_smile:

Jennifer:

I know EXACTLY where you’re coming from. I’ve read the other posts, read your responses, and I’ve felt the EXACT same frustration you’re feeling right now. There is a HUGE push to make everything CSS because of the way it’s supposed to make things more user-friendly, how it’s supposed to look better on cell phones and how it’s supposed to make the job of revising your site easier down the line.

I did NOT want to take the plunge into CSS because, let’s face it, it’s literally like learning a new language. I design my sites in Photoshop, slice 'em up and put them in a table in Dreamweaver. It’s how I’ve done it for the last 10 years, and I don’t see a need to change it.

However, Dreamweaver has seamlessly integrated CSS commands and functionality into their interface, so working with CSS has become a little more tolerable. Here’s my $0.02 for everyone: why not do both? Why not use CSS for the style elements (fonts, placement of pictures, etc.) and use tables to contain your sliced images?

I’ve worked on websites that were fully CSS and while it might have taken a second less to load, the format was (yawn) boring and the site was crippled when it came to customizing the layout.

(By the way, I have taken to learning CSS because I understand the value of it, and I’ve found some great classes at W3 Schools.)

W3Schools is great if you want to learn how things were done back in the 20th century but the two guys who created that site haven’t kept it up to date and so much of what you can learn there either already is or already is as outdated as using tables for layout.

The biggest benefits to separating content and appearance is that it can take a few minutes to make an appearance change by altering one CSS file that would have taken months of time to update the thousands of HTML files impacted by the change. Once Netscape 4 died there was no longer any reason to keep the two jumbled together and the sensible thing to do the next time you made a two month update to your layout was to also convert it so that any subsequent changes could be done a lot more quickly by having all the pages share CSS files to define their common layout rather than having it hard coded into each of the thousands of pages by using tables in the HTML.

Admittedly at the moment the float and positioning options in CSS work very differently to the way tables worked for layout but as soon as IE7 dies you’ll be able to start using CSS tables to define your layout just as easily as you could do it with HTML ones with the added advantage of still having the layout separate in just a few files where it will be much quicker to update the next time you want to refresh the way your pages look.

Sure, if you don’t have a problem with slicing and dicing a PSD then you won’t understand why you shouldn’t use tables for layout either. But when you decide to join the 21st century, you’re going to find a learning curve so steep it’s practically vertical.

Websites designed as PSDs may look pretty at first glance, but they are almost universally awful to use, and woefully inaccessible. And I would much rather build a site that is easy for everyone to use, regardless of what computer setup they’ve got, than one that allows them to admire its beauty for a couple of seconds until they get stuck because the layout fails miserably on their machine.

I’ve worked on websites that were fully CSS and while it might have taken a second less to load, the format was (yawn) boring and the site was crippled when it came to customizing the layout.

A lot of people made cruddy CSS layouts, I won’t deny that. Most of the time, that’s because they’re either not natural designers (so wouldn’t come up with anything fancier whatever method they used) or because they’re approaching the design from a table-based perspective, which is never going to work. Designing with CSS is a completely different process to designing with tables, so if you try to shoehorn your table-based slice-and-dice into a tabular grid CSS framework then it’s no wonder you’re going to get the worst of all worlds.

Have you ever looked at CSS Zen Garden? I thought it was old hat by now, but it sounds like it’s completely passed you by for the last 7 years. It has a vast array of different designs and layouts that all use the same HTML code. And if you think that the range of designs there represents “(yawn) boring and … crippled when it comes to customizing the layout” then I can’t even begin to imagine what kind of designs you need to keep your attention span.

With the web moving very much to mobile devices as well, you’d never be able to pull this off with tables.

Wow Paul! Thank you sooooo much. I really appreciate the time you took to SHOW me rather than tell me. Being the visual person I am, I learn by looking at examples. Consequently the sites that just talk about CSS properties I don’t find very useful.

I’m going to be studing what you did and try to figure it out. I have some questions.

It seems there are lots of different ways to accomplish the same task using CSS. Is there a “best practices” guide, or doesn’t it matter?

Is it okay if I get stuck on something to come here and get somet help?

I’m going to convert all the sites I’ve done to CSS. How bout I come here and have you guys do the CSS for me? JUST KIDDING! :slight_smile:

When I moved to CSS a few years back I got copies of Beginning CSS Web Development and Pro CSS techniques both from Apress. It took about a week or two to go through both books and I would suggest them to anyone coming from an html background.

The books I mentioned will feel like greek at first, but, taken in pace they really teach you a solid understanding of CSS. Sitepoint is a great place to ask questions too.

I usually suggest to anyone trying to learning something new to get a good book(s) and stick to it vs jumping all over the web into tutorials – doing this usually causes brain overload and confusion. Sorta like trying to rebuild an engine by reading instructions on a forum before you learn to change the oil.

Good luck on your studies and be sure to ask questions here at SP, there are many great folks eager to help.

Earlier posters have explained very clearly the advantages of taking the plunge and moving to css-based layouts, so I won’t go there.

But, leaving aside technical and design considerations, there is a very important Business Reason to make the change.

One day, one of your new clients is going to contact you and say: “Hey, I’ve just found out the website you finished for me last week is laid out with tables. My friend told me this is obsolete and no one uses this method anymore. He gave me a whole list of reasons. I’ve looked this up on the web and everything I read says that websites should be laid out using CSS. Tables have been obsolete for years, apparently. It seems like you’ve sold me old, obsolete technology at a state of the art new price! If I had known you were going to do this I would never have gone ahead! I’m very disappointed that you’ve let me down like this. I need you to change my site to a CSS layout. When can you have it ready?”

This is a disaster waiting to happen, and it’s lose-lose all the way.

Progress is not always convenient! But you need a very good reason to fall behind the times in the web industry, and there quite simply isn’t a good reason in the tables/css argument.

Paul

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_tutorials/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:

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:


<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&amp;sort=title&amp;order=asc" rel="nofollow">Title</a> /
<a href="forumdisplay.php?f=39&amp;sort=postusername&amp;order=asc" rel="nofollow">Thread Starter</a>
</span>
</span>


<span class="threadstats td"><a href="forumdisplay.php?f=39&amp;sort=replycount&amp;order=desc" rel="nofollow">Replies</a> / <a href="forumdisplay.php?f=39&amp;sort=views&amp;order=desc" rel="nofollow">Views</a></span>
<span class="threadlastpost td"><a href="forumdisplay.php?f=39&amp;sort=lastpost&amp;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!


<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&amp;sort=title&amp;order=asc" rel="nofollow">Title</a> /
					<a href="forumdisplay.php?f=39&amp;sort=postusername&amp;order=asc" rel="nofollow">Thread Starter</a>
				</th>
				<th class="replies">
					<a href="forumdisplay.php?f=39&amp;sort=replycount&amp;order=desc" rel="nofollow">Replies</a>
				</th>
				<th class="views">
					<a href="forumdisplay.php?f=39&amp;sort=views&amp;order=desc" rel="nofollow">Views</a>
				</th>
				<th class="lastPost">
					<a href="forumdisplay.php?f=39&amp;sort=lastpost&amp;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:


<table cellspacing="0" cellpadding="0" border="0" class="myTable">
	<tr>
		<td colspan="4" class="bigTitle"><b>Table Title</b></td>
	</tr><tr>
		<td>&nbsp;</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, &nbsp 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:


<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.

I cringed when I saw this. Content, Behavior, and Presentation separation is VERY IMPORTANT. Sorry to troll, but it’s essential to do so because it helps the site development in the long run. Say a style is breaking the site. Instead of going back to the content and screwing that up, guess what you get to do? you can make the change on the CSS or revert via SVN without losing any content changes. Or changing the layout. It should be standard to separate these for error trapping and further customization.

And kudos to DeathShadow60. Good demystification there!