Forum Moderators: open
Heh, heh. You're talkin' RELIGION, here! Strap yourself in...
Here are a couple of my own rants on the topic:
[webmasterworld.com ]
Basically, my take is that the Zeldmanites are pretty much correct. You are better off not using <table> elements for basic page layout.
MOST of the time. However, there are a couple of times that they are the best solution to a layout problem.
I like to use the "modern" layouts (<div>-based) whenever possible. It is sometimes a fair amount more work to make it work on all browsers, but it is generally worth it, especially if you are designing pages to be displayed on cellphones, printed in a custom manner or read as RSS. There is argument that a "modern" page is more efficient for SEO than a <table> page, but I suspect that this has more to do with the way you can toss <div> elements around.
I'm a practical person. I'll use whatever tools I need to use to make a site that works, and works well. I can't afford Kool-Aid.
I will say as a recovering table junkie - I attempt to approach every problem as tableless unless situations arise that prevent it, such as site owner editing, etc.
The bottom line is that tables are for tabular data. Semantically this is what they should be used for. When cornered and no other solution is working - table it.
Do tables kill you in the search engines? No.
Are tableless documents "smarter" documents? Yes. You use divs for generic page divisions, paragraphs for paragraphs, lists for lists.
Does it make your code more pure and correct, expose your content more clearly? Definately.
Does it boost your ego, make you a better coder? Results vary. :-)
Although CSS purists talk about separating presentation from content, you can't really do it to near the degree you can by just writing content in XML.
One of the biggest hassles with tables is their tendency to become unreadable as you create more and more nesting to get all the positioning where you want it. But with XML/XSLT, you can modularize all that complexity and keep it totally separate from your content.
But with XML/XSLT, you can modularize all that complexity and keep it totally separate from your content.
You are absolutely correct.
However, coding in XML and XSLTing it into specific XML DTDs as standard industry practice is still a ways off, and isn't yet supported by the kinds of tools that would make it mainstream.
I plan to learn to do it this way, sooner or later (probably sooner than later), but there isn't a significant advantage to my doing so right now. I'm quite capable of learning up on it, I've been a C++ programmer for a couple of decades now.
Semantically, I don't think it's much of a problem for agents (like search engines) to distinguish between TABLEs that contain tabular data, and TABLEs that are used for layout. Most of the time, TABLEs containing tabular data have some kind of header, so have THs, or a THEAD. They may also have a CAPTION. So the presence of any of these three indicates a TABLE with tabular data, else it's for layout.
And that makes the question of whether you "should" use TABLEs only for tabular data a non-issue. It is in fact not a semantic problem for agents, as purists imply.
Other than that, I'm usually better off tossing <div> elements around.
The whole "upgrade your site with CSS only thing" tends to be a dud. I have yet to upgrade one single site where all I did was switch in a new set of CSS and images. I ALWAYS upgrade the structure as well as the presentation. I have also found that real CSS work is complex as hell (just read the comments on this forum). It is my experience that designers are not actually interested in writing CSS. They give us Photoshop layouts, and expect us to write the CSS to realize their dreams (and are a real pain when we tell them that we can't give them what they want).
I always laugh when someone says <table> elements are evil, then in the same paragraph, starts extolling the virtues of mutating <ul>, <ol> and <dl> elements, or making a <div> look just like a <table>.
If the task calls for a <table>, then use a <table>. It is one of the oldest and most well-supported elements in the lexicon.
That being said, I usually consider it a challenge to do without them, and will do my best to write code that meets the challenge.
As long as it renders properly on every browser back to IE5/Win98 (We just decided that our next site can forget about supporting NS 4.X).
> tables over css.
I have yet to run into a case where CSS is better than standard rock solid tables. There are just too many incompatability issues to deal with yet to consider tables. Unless you don't care about your visitors.
If you could increase your visitors by 10% - how much money would that make you? Imagine if 10% of your vistors are using "not ie" and "not firefox" browers. (which it is a pretty good bet that 10% is a low figure)
Try visiting your site with a Palm Treo 650, and then with a 700. What? You don't have a 650 or a 700? Ok, try it with a Razor, or a Chocolate. Don't have one of those either? Ok, how about firing up a Samsung i730, or a Blackberry? hmmm.
(Now you know how your vistors feel when they hit your all CSS site, cuz they can't see most of it or it looks like *el and won't layout in any semblance of decency)
If you do run CSS, please test it as best you can with alternative viewers. Best bet is to run Opera and look at your site with some of the alternative layouts (accessiblity, mobile, fit-to-width, small screen). Then nuke the CSS (ctrl-G) and see what the layout is then. That will tell you what alot of mobile users are going to view your site as.
Also, fire up your mac and look at the site in Safari. With the iPhone coming in a few months, it is a sure bet that mobile usage is going to increase signficantly. The version of safari in the iPhone is said to be a stripped down desktop version. It is a safe bet that the rendering engine is going to have issues with heavy css sites.
> keep it totally separate from your content
That way, you can increase your maintenance and work load by a factor of two! Why spend that free time out laying around on the beach when you could be at the office managing all those divs and classes. Why skip that back 9 when you could be slaving away at home trying to manage the chaos between your multiple files and css sheets to get them to perfectly sync ;-) Who cares about CSS bloat - everyone is on broadband right ;-)
</counterpoint>
Brett_Tabke
Like I said, Kick -> Anthill.
He's absolutely right. If you want to cry, try hitting your site with a Blackjack (I have one).
That's one of the reasons I set up alternative WML pages for the sites that matter. Even Handheld media CSS can be painful, as the data still gets streamed out -S L O W L Y A N D E X P E N $ I V E L Y- to your phone.
I use a Mac with multiple Parallels VMs for testing, and I tend to hit my sites with at least ten different browsers, two cellphones and six or seven validators. I run colorblind simulations and generally practice sadism on the sites. When I design sites, they need to support old browsers running on crappy 20th-Century hardware with dialup modems (they tend to be NPO sites that cater to relatively disadvantaged people. I say "relatively" because you won't see too many REALLY po' people using a Web browser).
Some of the sites I design may save lives. It would REALLY stink if someone died because I wanted to drink some academic Kool-Aid.
There's something called "Reality." It doesn't publish well, nor does it sit well in the craw of absolutists or idealists. It doesn't have a flag, it doesn't have a manifesto and it doesn't have an anthem. It has no sexy spokespeople and it has absolutely no compassion or flexibility whatsoever.
who uses tables for layout: Yahoo,Google,MSN,AOL, etc. you just can't get away from the truth...
Tables define my page layout, period. CSS defines the attributes that I want to apply to those tables and everything within them. The style sheets simplify the maintenance of that site. If I want to change a color, or a width, or a font, or whatever.. I change it one time in the style sheet and that change is applied sitewide. Make the most of both.
Having said that, I am not opposed to using a CSS layout, and I have done that with another site. Besides being a LOT of trouble, in the end that site really only looks good on one browser, and is passable on some others, and probably useless on many more.
In the final analysis, I can't justify spending hours/days tweaking a page to make it right for every browser when I can JUST DO IT with a table and a simple style sheet.
Tables! a YES YES
Yes, when you've been using tables for years, the CSS learning curve can be painful and time consuming at first, but once you've 'got it' it becomes natural and as easy as tables once were, and with added practical benefits.
In my experience tabular layouts are no more cross-browser/platform reliable than CSS ones. For both it depends on how well the page is put together.
Having made the switch to pure CSS I personally would never go back to tables. I design for Firefox, tweak styles for IE using conditional comments, and make use of handheld and print stylesheets. I find it perfectly practical, not just idealistic.
So forgive me for philosophizing here, but it seems the world is often devided into two camps: those who want to sit on the beach and make money, and those who want the world to be better. History shows that the beach camp usually wins, not only because it is much bigger, but because it is easier.
I'm not supporting either side here, tables or css. But I wanted to mention that I think this argument is not really about tables or css. It's about mentality. You could just as well substitute gas-car/electric-car or anti-recycling/pro-recycling and the debate would be the same.
The one side says if we work hard and smart, the world could be better. The beach camp responds with a variation on this theme "why would I ship my chemical waste to Nevada, when I can just dump it in the stream behind the factory? It's so much easier".
As we all know, the only way to stop behavior like this is to impose legal restrictions with heavy punishments. Since that is impossible on the Web, I don't see any change in sight.
The internet has often been compared to the Wild West. In the absence of strong authority in town, people take the law in their own hands. The table/css debate is one of the many shoot-outs going on.
The lesson that the standards-makers fail to learn over and over again is this: make it easy and people will do it.
To give Microsoft credit, they may break a lot of rules, but they also have pioneered a great many of the technologies that are just starting to "pop," like AJAX and CSS :hover pseudo-classes.
Once a standard has become accepted, then there is an inevitable "hysteresis," in which you have to wait for the technology to "age out." That seems to be about five years or so. A LONG time in technology years.
We will be revamping one of the sites I've written, and we've finally given up on supporting NN4.X. We still need to support IE5.0.1. I'll try and get them to accept 5.5, as it supports CSS better.
As a Web designer, it is slightly more difficult to design "transitional tech" pages. For example, here's how you might design a popup menu that reacts well to JavaScript-enabled browsers, but allows non-JS browsers to work as well:
<form action="#" method="get">
<div>
<select onchange="this.form.submit()">
<option value="" selected="selected">Select an Option</option>
<option value="1">1</option>
</select>
<noscript><input type="submit" value="Go" /></noscript>
</div></form> There is also often a real penalty for being a "first adopter." I program Macs, and I very well remember Apple pushing OpenDoc, QuickDraw GX, etc. as the "wave of the future." The people who drank THAT Kool-Aid went broke.
It's true that layout tables are simple to mark-up, easy to maintain and have shown themselves to be a robust, cross-platform, 2D design solution.
But they "do the job" only in a very narrow sense.
They do the job for human visitors using a visual browser. And for pretty much every other user-agent - a browser with a screenreader, a text-only browser, an indexing spider - they can and frequently do mess up the document.
Putting your entire document inside a table means that you think HTML is some kind of desktop publishing tool, rather than a language for describing document structure.
This is very much missing the point.