Most people will say CSS is the way to go. There are a few who say go with whatever you want. My question is, what is the benefit of CSS? It seems like it's less browser-capatible and has the potential to overlap. Plus, it's a whole lot harder to code. With tables, it's easier, it supported, and the worst that can happen is you have to scroll sideways, but at least nothing gets hidden. Why even bother with CSS?
A big page designed with tables can get very very bloated compared to a CSS page. The file size in a css layout would be a lot smaller and faster to load. Also the layout is all in the CSS, so you can redesign your whole website and it looks the same to the search engines not to mess anything up.
It's purely simple. Tables were designed for TABULAR data. Divs wre designed for the use of CSS. I personally do all my designs using divs, lists, and CSS. I can make a very simple div structured HTML site and completely redo it using CSS to make it look sweet. Tables are evil, I just don't use them unless I'm forced to.
I have sites that are pure css and other that use a tables and css. You are going to get some pretty fierce arguments from css purests, but I've found that there are some things that simply cannot be done better with css without bloating the code or utlizing hacks to correct for cross browser bugs. It really depends on what design you have chosen for your site. I would stay away from nesting tables if at all possible, and generally speaking, a css designed site will have less code i.e. load faster. I love css, but taking a stance that you should never use tables is a mistake imo.
Depends on what you are designing your site for. Most mobile devices don't support CSS and javascript, so if you want your site accessible from say a Sidekick, you might want to use standard tables. Plus not all CSS is compatible across all browsers. Tables have been pretty much supported from the early 90's. There are other things to consider as well. Are your pages printed frequently? Do they require the user to save them locally? All these external porting features need to be tested more thoroughly with CSS. Depending on your printer driver, some features of CSS won't print properly, etc. Another comparison... if you need to have a web page open in excel, etc. Tables will work better.... To summarize... there is no easy answer. But my opinion is, when in doubt... use tables...=)
I would suggest that if you're creating a site for mobile devices, you need to move it to an XML format or like style and auto-detect the mobile-device, such that Google does, and redirect to the WAP enabled portion of your site.
I once tried a redesign from tables to css (for positioning, not formatting). After a bunch of research I found that CSS zealots like Zeldman consider a 3 column layout with a fluid middle column a great achievement rather than a 3 minute triviality. I even saw some Javascript suggestions just to get a simple footer working! Here's a great article from the cantankerous jwz (of the original Netscape fame) on why CSS sucks http://www.livejournal.com/users/jwz/193866.html (remember, this is one of the early Netscape 1.0 coders, not an airy-fairy "designer") Choice quotes:
code size able to modify layout without updating the html (if you're using a separate css file) complex table layouts often don't follow accessibility guidelines For the accessibility point, refer to the W3C's Web Content Accessibility Guidelines 1.0 which says "Do not use tables for layout unless the table makes sense when linearized." Basically, if you have a table layout that looks fine in a normal browser, but is a mess in the source, then it will read out of order to someone with a special web page reader.
If you're using it for formatting it allows you to update your whole look with changes to a single file. If you're using it for layout...don't use it for layout. It's not cross-browser compatible and why try to solve a problem that was solved in 1997 with tables? Concentrate on making money, not scratching your head on why things look different in every browser
Btw I registered CSSsucks.com a while back I'm planning a community of people who don't drink the CSS koolaid
Have you read this thread yet?: http://forums.digitalpoint.com/showthread.php?t=33332 I'm not a purist by any means, but I see the logic in css over tables, especially for bigger sites with higher traffic. The bandwith issue, ease of redesigning an entire site with a single stylesheet, better search engine visibility, and ability to set separate styles for separate browsers & media all are viable reasons to opt for css. And then there's accessibility... If you're prime concern is that your site looks pretty for old browsers, use the standard table. BUT, if you want your site to be accessible to "alternative" viewing mediums (for disabled or otherwise), or if you're interested at all in being ahead of the game rather than on yesterday's trend, use css. The internet, like anything else, evolves. Expect CSS to become the expected and accepted norm and for the nested table layout to become extinct for it's cumbersome code.
If you want to do a simple 3 column layout (with header and footer), I have to admit you're probably better off just using tables. As I've been playing with CSS and converting old table layouts to css layouts, it has been a very frustrating experience. I'm totally against syntax hacks to get things working cross browser, so that's made it even more difficult. Yet I still recommend using CSS for layouts. Maybe I'm just trying to be trendy. What's sad is I find myself looking at people's html source, and if they still have a table layout, I lose a little bit of respect for them.
You can apply CSS to table exactly same way - using an extrnal styles sheet file. W3C created this guideline in hope that all browsers will comply 100% with the HTML/CSS spec and that both of these specs will offer a reasonable alternative to using tables for layouts. Well, they don't - take a look at how much stuff W3C is about to put into CSS3 to realize how much is missing from CSS2. Here's one good example - in CSS2 it is impossible to create a shrink-to-fit box without using floats or absolutely-positioned elements. Here's simple table-based HTML that centers two different-sized pictures (it will work with content of any size without having to specify its width) on the page and look exactly the same in all browsers: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <style type="text/css"> table {margin: .5em auto; border: 1px solid #A98; border-collapse: collapse; background-color: #FFFFF5;} td {padding: 5px 5px 0 5px;} div {text-align: center; font: bold 8pt sans-serif; padding-top: 2px; padding-bottom: 2px;} </style> <body> <table><tr><td> <img src="http://www.xbox.com/NR/rdonlyres/F7CFF0A9-168C-4E14-B20D-5D17BBC1036F/0/3cgsprojectgothamracing3_nogamelogo.jpg"> <div>Caption</div> </table> <table><tr><td> <img src="http://www.xbox.com/NR/rdonlyres/5236DCA4-27FF-40E7-9A79-D5BDF1DE77C8/0/pbh_473x180callofduty2bigredone.jpg"> <div>Caption</div> </table> </body> </html> HTML: Now, try doing this without tables. When W3C adds all the missing parts to the HTML/CSS specs (such as shrink-to-fit width) and when all browsers implement it to a reasonable extent, then we can talk about using tables only for tabular data. Until that time, tables are you friend where it makes your life easier. J.D.
But are you able to move table cells to a different position on the page? I'm not saying a webmaster will need to do this every day, but it's a point that's demonstrated by css Zen Garden
The key phrase in post was "tables are you friend where it makes your life easier". If I need to move around a shrink-to-fit box, I will move around the entire one-cell table. If it's just a fixed-size box or if it's an absolutely-positioned box, a div will produce simpler and easier to maintain markup. J.D.
I suspect that even if/when they manage to do that the additional complexity just to get simple things working will be a deterrent. Also, as the specs get more and more complicated it's more likely that the browser developers will have different interpretations. Personally I think they should admit that the original CSS spec was poorly thought out and incomplete, and just start fresh with the lessons learnt. I think it's amazing that considering they started from a blank slate they still ended up with something so mediocre. Agree 100%. My philosophy is to use whatever is fastest and gets the job done.
While I agree with your other points, I think W3C did an excellent job putting CSS together - except a couple of ambiguous paragraphs, CSS2.1 is very well-written and thought-through. One thing that still amuses me is that for some reason the average webmaster keeps thinking of CSS as if it's an alternative to tables - statements like "CSS vs. tables" are all over the web and people avoid tables so religiously that often it just doesn't make any sense (completely redefining the meaning of the <ul>/<li> elements for menus is one example of this). As I have said before, CSS complements tables (and HTML in general) and should not be thought of as one concept vs. another. J.D.
Whoever said that CSS makes pages less supported by other devices such as a mobile is just ignorant. One of the biggest points of restricting your HTML to pure semantic markup is so that the page is usable in *any* medium. It could be a braile browser, a page reader, a palm pilot or absolutely anything else. Pure (and correct) HTML is 100% portable. CSS is about allowing the site to be extra flashy for those devices that are capable of supporting the extra graphics. Tables are bad (for layout) because they break the semantic markup principle that is the basis of HTML. Suddenly devices no longer have a way of knowing if the relationship between rows and columns is vital (as is the case if we are dealing with actual tabular data) or if this relationship should be ignored completely. Why CSS is good. Assuming you have coded your page the way it is supposed to be coded (by that I mean what the inventors of HTML and the WWW intended it to do) then there is no other way to style your page. But more than that, CSS gives you much more control over the visual appearance of the page. The page is also extremely adaptable to design changes. The entire look and feel of the site (whether dozens, hundreds, or even thousands of pages) can be instantly changed by swapping a single file. The CSS Zen Garden is the perfect example of how powerful this can be. Consider each of the following pages. http://www.csszengarden.com/?cssfile=174/174.css http://www.csszengarden.com/?cssfile=158/158.css http://www.csszengarden.com/?cssfile=075/075.css Notice that the HTML code for each one is identical (excepting for the different CSS files being referenced). You can also open up any of these pages in FF, IE6 or IE5 and notice that each page looks just as is expected. So all those people who said CSS is incompatable can go bite themselves because that is the only good thing that can come from you opening your mouths. If you can not get it to look correctly in the various browsers it is because you do not know how to use the language properly. Which brings me to the next point. Is CSS hard? The answer to this one is a little bit of yes and a little bit of no. Many people have probably spent the past decade making their layouts with tables. For these people switching to CSS layouts will be hard. You're learning more than a new language syntax, you have to learn a whole new way of thinking about how the elements are laid out on the page. I used to make pages with tables. I had to go through this transistion too. It is not easy and it will not happen overnight. But once you become accustomed to it you will find yourself wondering how you ever managed with mere tables.
I've just started playing with real semantic design. And I've spent far more time than I would have expected trying to get everything "just so." After reading some of the comments here, I'm starting to question my original intent of doing away with tables. If it means I have to stay up until 4am trying to get rid of some stupid space that shows up between div tags in FF only, maybe my time is better spent on the actual meat of my project. Anyway, it seems to me that semantic design works best when the website in question is text and colored boxes and very little else (like basecamp and almost every blog). But when you're working with a very graphical presentation, you are forced to use the background style for purposes other than its original intent, which introduces little cracks in the whole semantic design approach. That was the problem with table-based design in the first place. Tables are used for purposes other than their original intent. I'm no expert. That's just my take on what I've learned so far.