One of the debates that never seems to go away in the web development community is that of css vs tables and which is better to use for the layout of your site. I’m surprised this debate continues, though admittedly I’m continuing it right now after the question was raised on my small business forum. I think much of the reason css vs tables is still debated is the misinformation people on both sides put out there. Hopefully I can clear up a few things in this post and let you make your own decision.
Let me start by letting you know I fall on the css side of things. Having developed and worked on sites both ways I’m 100% certain structuring your layout with tables is not the way to go. However, you can build a great site using tables and a poor site using css. To compare we really need to look at sites that are well developed on both sites.
Let me also say that if you prefer to develop sites with a table-based layout, good for you. I’m not going to tell you that you’re doing anything wrong or evil or that the world is going to come to an end. I do think css is the better option, but feel free to develop sites any way you want.
photo credit: Marjan Krebelj
What This Debate is Really About
Calling this debate css vs tables is actually inaccurate. You can use css with a table-based layout. One argument the css side always uses is that having your presentation in a separate file makes the site easy to maintain. That is true, but you can have all your presentation in a separate css file while having a table-based structure to your html.
If you originally decide all your h1 tags should be blue and later want them to be red it’s certainly easier to have your h1 style sitting in a single css file. You can do that regardless of how you structure your layout. That would be a debate between using css or html attributes for presentation. I don’t think anyone is arguing in favor of html attributes.
What the css vs tables debate is really about is whether or not to structure a web page with tables or divs. In its simplest form we’re comparing:
{code type=html}
| Some content here |
{/code}
and
{code type=html}
{/code}
The Problems with Tables
Even in the simplest case above you can see tables are already a more complex structure than divs. We needed three sets of tags to present some content as opposed to the one set of div tags. As we add more to the page’s design the table complexity continues to increase compared to divs.
In the best case scenario you’d be adding at least another table cell to get another block of information compared to adding another div for another block of information, which would grow our code equally. Most of the time though, that relationship won’t be 1:1. It will usually involve adding more tags on the table side as compared to the div side.
More code leads to more potential for errors. Software developers have known that for years and it’s equally true of the code used to develop a web page or site.
That brings us to the second problem with tables. They impose a more rigid structure than divs. Every table cell is dependent on the other table cells in its row to maintain the structure. Divs can work independently from each other. You can’t pluck a single cell out of a table and move it somewhere else in the layout. You can’t break out of the rigid grid easily. You can with a div.
Suppose you have a typical two column layout (content and sidebar) and you wanted to reverse the order. Maybe you want to move the sidebar from the left to the right of the content. With a table-based layout the only way this would be possible would be to go into every page of your site and change the underlying structure. With a div-based layout you could make this change in your stylesheet alone. Granted it’s not the kind of change you’re likely to make, but as an example it shows the greater flexibility and control you have in developing with divs.
The third problem with tables is in how browsers render them. In order for a browser to render a page built with tables it needs to read the code on the page twice. Once to understand the structure and another time to present it. That extra pass at the code makes table-based layouts take longer to display. With a simple table structure the extra time might not be noticeable, but as the structure becomes more complex with more and more tables nested inside each other it is noticeable.
If you ever visited a page that showed nothing for a few seconds before everything suddenly appeared, that time was likely your browser making it’s first pass over the table structure behind the page.
The Advantages of Divs
The advantages with using divs are essentially counter to the problems with tables described above. A div-based layout is:
- easier to maintain – less code and less complexity to the structure makes things easier to find and change.
- more flexible – since one div is not dependent on the other divs on the page it allows for more freedom in your design
- quicker to load – blocks of code can be presented right away instead of the browser requiring an extra pass
That might not seem like a lot, but just those three things are enough to make a div based approach better to a table based approach. Now let’s get to some of the myths on both sides that keep this debate going.
photo credit: Detlef Schobert
Myths About Divs and Tables
I mentioned at the start of this post that misinformation spreads on both sides of this debate. As people combat these myths the debate goes on and on combating misinformation while dancing around the central issue. Let’s see if we can dispel a few myths from each side
-
CSS (divs) are better for SEO – Search engines don’t care one bit if the code behind your page uses tables or divs. Search engines are interested in your content, not your code. It’s true that less code means less potential for show stopping errors, but those show stoppers can exist regardless of your site’s structure.
Some might argue that the content search engines see on the page is more important and through divs it’s easier to present a different order of content to visitors and search engine spiders. It is easier with divs, but it can also be done with tables.
-
CSS (divs) are more accessible – Both tables and divs can be coded to be accessible or inaccessible. You’ll have more control over how your page displays with divs that can aid in how a screenreader sees your content, but again you can create equally accessible pages using either approach.
-
CSS (divs) is hard to learn – Simply not true. CSS is not hard to learn.The argument is made by people comparing learning something new to learning something they already know well. That’s not an apples to apples comparison. Laying out a site with divs has a learning curve. So does laying out a site with tables. The problem most people have when learning to use divs is trying to force them to act like tables instead of allowing them to be what they are.
Even if we accept the argument that learning to use divs is difficult that doesn’t make tables a better approach. The best things in life are not necessarily easy or easy to learn. Not doing something because it takes time to learn is laziness.
-
CSS (divs) requires too many hacks to work cross browser – Entirely false. Perhaps it’s a matter of experience, but if you know what you’re doing you never need to use any kind of hack. It’s been years since I wrote more than a few lines of code specifically for any one browser and none of that code is a hack.
If you develop to standards at most you’ll need to tweak a few things for Internet Explorer and usually only older versions of IE. If you find yourself needing hacks then most likely you haven’t thought out your structure all that well.
-
It’s quicker to develop with tables – Nope. I guarantee I can develop a page with divs quicker than you can develop it with tables. This argument usually includes the time taken to learn to use divs, which isn’t a fair comparison. Take two developers, one who is fluent with tables and one who is fluent with divs, hand them a layered PSD file and ask them to code a web page to see who finishes first. My money will be on the person using divs.
Conclusion
This is one of those debates that never seems to go away and I guess I’m not exactly doing my part to make it go away with this post. I find it hard to believe that anyone who honestly knows how to develop a site well with both tables and divs would ever choose to use tables. Having used both it’s very obvious to me that the div based approach is the much better way to go.
There are a lot of myths propagated by both sides in this debate, but once you cut through most of them the argument really boils down to a few things.
Divs require less code and are less dependent on each other than tables. That leads to easier maintenance, more freedom in design, and quicker load times. Those arguments alone should be enough to tip the scales in the argument. Everything else is really irrelevant.
Download a free sample from my book, Design Fundamentals.
I feel like one of the reasons that tables are still so widely used are the WYSIWYGs. Learning CSS/div coding seems a daunting task because they dont really know the code in the first place.
I think anyone that codes by hand knows that CSS/div is easier to work with in that way.
If there is anyone that actually codes full table-based websites by hand I would be curious to know what reasoning they have for not switching.
You might be right about the WYSIWYGs.
When I first learned how to develop a website I learned to build them with tables like so many others. Then I had to make changes to one site and thought there had to be a better way.
Enter css and I’ve never looked back. To me it seems so obvious that using divs over tables is the better approach that I have a hard time understanding how someone would argue otherwise.
But clearly there are many people who support using tables. If you click through on some of the links in the post or just do a search for css vs tables you’ll come across a lot of the reasoning why some prefer tables. I don’t agree with their reasoning, but it is there.
That’s easy. With tables you know exactly where you are placing your content, exactly!!! With divs it’s just guessing, “maybe this will work”. Many div’s require way too much css to make it worth your while. It’s is also much quicker to use tables, and hey, yeah, once in a while it is nice to be able to glance at your code in a wysywig and actually see what it looks like.
Funny. I’ve been using divs for a decade now and never once had to guess where the content would be. Divs don’t require complicated css.
Most of the time when someone presents code showing the complicated css they “needed” the problem was their general approach. The complicated css wasn’t a requirement. The person usually chose a complicated path to solving the problem when a much simpler path existed.
Very interesting information. I am about to take on a new website project, first one in 8 years. I’ve done a few and have always used photoshop for layout and then created html tables based on that layout. I’m going to remain open minded and give CSS a chance! Wish me luck. Once a again, thank you for the info!
“he argument is made by people comparing learning something new to learning something they already know well.”
I think you hit the nail right on the head with this comment. CSS based design is unquestionably superior to table layout, but due to sheer laziness the practice of table design has held on. I find that unfortunate, as someone who caught the tail end of the “table era” I find it much more difficult to maintain a website which uses tables (because of my own lack of experience with tables I suppose) than to administer a website which uses a CSS layout.
Very informative article and I hope that it gains some traction so people will stop using so many tables for layout.
I feel the same about maintain tables-based sites. I’ve worked with both, though certainly more with css sites. What makes tables harder is that it’s too easy to get lost in the structure and edit the wrong cell.
Top to bottom you seem to sum it up pretty well. I’ve never read about this debate until now, however in the back of my mind I always knew someone(s) was debating it.
I too started out doing HTML with tables, and as soon as I saw the CSS light, I’ve never been able to see it any other way. The only time I ever use tables anymore is to quickly horizontally and -vertically- oppose an image or something else on a temporary coming soon type page.
One debate I’m honestly curious about is the best way to go about table type content with CSS, such as using the actual table properties, using display: inline, using float: left, etc — where’s that write up? (i know there’s gotta be one but that’s almost another argument for CSS over tables… multiple ways you can go about it even).
Thanks Kevin. This debate has been going on for years. Do a search for css vs tables or similar and you can find a lot out there.
When you ask about table type content with css do you mean using css to show tabular data or are you asking more about how to style tables?
If you’re asking about the former then I’d say go ahead and use a table when you’re presenting data in columns and rows. If you’re asking about the latter that’s a good question. Maybe I’ll have to write a post on styling tables. I’m sure there are a few out there already, but one more won’t hurt.
It amazes me that some folks still use tables for layout in this day and age. Back in 2003, I gave my presentation, Why tables for layout is stupid, at Seybold (http://blog.hotdesign.com/2008/10/what-is-css/) about the advantages of CSS layouts. And, if anything, those advantages are more pronounced now than ever. Heck, even IE8 does a decent job of rendering CSS layouts.
As I see it, table layouts have precisely two advantages:
1. Outlook 2007 has a brain-dead rendering engine, so if you’re producing HTML e-mails, you need to use tables.
2. Table cells are the only elements in HTML that expand and contract based on adjacent content.
That’s it. If you’re not creating HTML e-mails, or unless you have some overriding need to have part of your page scale because of the amount of content on other parts of your page, there’s no reason to use tables for layout.
I hear you Bill. I’m amazed this conversation still exists yet it seems every few weeks I see another post proclaiming we should all go back to using tables for site layout.
Nice presentation by the way. The comics are great.
The one that continues using tables is because it does not dominate or does not know CSS. To design in CSS is far better, by the subject of order, maintenance, accessibility, navigability and thousand reasons more.
My thoughts exactly.
My homepage is currently structured with divs. It was easy to do, and it looks great in Opera, Firefox, and Chrome, but guess what?! IE sucks and makes my page look a pile of crap. I need to write special code for IE? How is that more maintainable?
I’d rather switch my page to tables, than screw around with IE. I don’t even have a copy of IE to work with. I agree that CSS is much better in theory, but as long as people use IE and Microsoft refuses to be standards compliant, I don’t think CSS for structure is the greatest idea.
Just because you didn’t get it working on your site, don’t blame css as though you can’t build a site that works across browsers. This site uses css and works in IE for example as do many, many others.
IE is a lot more standards compliant than you’re giving it credit for. It certainly lags behind other browsers, but for the most part IE fro version 7 on is css2 compliant.
CSS is better in both theory and practice. You do have to put in a little time to learn how to layout a site with css, but once learned it’s not hard to do.
I can understand your frustration, but it’s not the fault of css. Many people are able to build sites using css as a layout and getting them to work cross-browser including IE without any difficulty.
I come from a developer background and am now working as an SEO consultant (I know, Boooo and all that) so I am definately an advocate of divs and I have to disagree with:
‘Search engines don’t care one bit if the code behind your page uses tables or divs. Search engines are interested in your content, not your code.’
I agree to an extent but I have here 2 very good reasons why tables are definately worse for SEO:
1. Accessibility issues arise more frequently due to excessive coding – ok so this can be attributed to bad coding but it’s such a common issue that it has to be taken into account
2. As you mentioned, pages built in tables have to load twice (something I didn’t know until reading this post) add to this that the example you showed:
Some content here
and
Some content here
clearly illustrates how much extra code is required for tables. With many sites (big, e commerce sites for example) having many different sections of text and images and other media throughout a page the code just grows and grows, taking browsers longer to load page content.
With Google’s latest algorithm update (Caffeine) emphasising page load times as a SE ranking factor it is now more important than ever from an SEO stand point to reduce the amount of code on a webpage.
You make good points. As far as the speed issues, Google didn’t really talk about load times affecting ranking until after I wrote this post. Now that they have indicated that load times will be a ranking factor I would agree that divs make more sense.
I’m not disagreeing with anything you say. I guess I’ve never been convinced of the seo benefits. Even though I think css is the better way, I’ve seen some very poor and slow loading css driven sites and some pretty well coded and quick table driven sites.
I think there’s more potential for errors with tables, but I know there are people who can code a search friendly site that’s still table-driven. I would never develop the site that way, but I know there are people who can. You can still develop an accessible site with tables. Even thought there’s more potential for errors, it doesn’t mean there will be errors.
The load time though, is now reason enough to recommend css over tables for seo. I just wrote this post a couple months before Matt Cutts mentioned how some at Google were pushing for that to be a factor.
By the way sorry the code in your comment didn’t display. I’m not logged into the site right now, but next time I am, I’ll see if I can fix it. The secret is you have to use < and > for the angle brackets or it gets interpreted as actual code. You can probably also wrap the code in a blockquote.
Regarding Google using load times, does that mean that if your server is on a lower bandwidth connection, or on a slower server that Google will hold that against you, or do they have a way of disregarding those variables and just base it on how long each page would take to load if bandwidth, lag and server response were constant?
All indications are the speed thing is a minor part of Google’s algorithm at the moment. It’s the kind of thing that might move you from #8 to #7, but not from page 5 to the first page.
Odds are though they would look at every data point they could so I would think a slower server would mean potentially worse ranking.
Again it’s probably not a huge difference either way at this point.
I’ve heard the argument that reduced code helps with SEO, with people saying that too much code makes it harder for Google to parse. Sure if in some Mexican sweat shop, 5 year olds were parsing pages for Google that may be true, but parsing text is as basic as programming gets other than typing “hello world” on the screen…I really doubt that’s an issue for Google, or Yahoo spider programmers. I certainly haven’t seen anything to support the validity of these remarks.
Which is why I’m not one to generally make that argument. I do think more code means more chances of making a show stopping kind of error. I also think that more code means more work for a search engine spider.
Assuming no major errors I think the search spiders will get through your code fine whether it’s css or tables. However my make them spend more time parsing if you don’t have. It could mean one less page they get to crawl on your site.
Again though you may notice in the post I don’t use seo as a reason to use css. I did list the seo benefits under the heading Myths.
Great debate. I would have to say,use divs and tables for what they are designed for. If you want your page to behave like a table or part of it, use a table.
For instance, if you want colmns with different colour backgrounds to be the same length, use a simple table and style it with css. Then you can use divs inside your table.
I have nothing against using tables. In fact I use them all the time when I want to present data. The key issue is not to use tables for the layout of your site template. That’s always going to be better done using css.
I am currently a consultant with an enormous company that forces us to support IE6. I am in the middle of a major project that we tried to code with proper CSS, but it’s incredibly frustrating and time consuming. If you need to create a modern site that supports an older browser, CSS imposes huge costs. This is simply not a point I am willing to debate.
My primary UI guy is a CSS ideologue and spends half his time fighting with stylesheets to make it work in every browser. Items misaligned, trouble getting the position of floated elements, absurd hacks, you name it. Eventually it works, but at what cost? Believe me, the clean code you talk about it gone. In my career I have worked with two types of people, fanatics and realists. Saying things like, “all people who use tables are…” quite frankly is absurd. Tables are still very useful for layout given that most sites are still essentially boxes that never move, but adjust in size as needed. CSS is very useful for styles regardless of how you do the layout.
Sure you can move stuff around easier with divs “just in case” you need to in the future, but nobody ever does. I also kept all my university textbooks “just in case” I would need them… guess what?
Some times you just need to get it done and move on. I support reasonable use of tables for backward compatibility.
Yes, but you can get it done just as quickly with css. If you aren’t it’s not because of the language.
If you read the post you’ll see I never once said you couldn’t use tables. I understand people have old code and sometimes they just need to fix it. If you’re constantly having to fix old code though, I would recommend looking into the feasibility of redeveloping the site. Maybe it’s not feasible in your case, but it might be worth looking into.
Nothing in this post is meant to condemn people from using tables for site layout. If your dealing with a site that was built with tables then you’re probably going to continue using tables on that site.
However please don’t imply that css can’t work for old sites or makes it more difficult to work on an existing table driven site. Neither is true.
very nice article, good job, i wanted to add my comment based on my own humble experience.. CSS is like a a sword, once you master it, you could be a powerful warrior, and if you truly go advanced with it, you’ll never ever consider tables… once you start writing complicated web apps, that consist of heavy javascript code for the layout, you’ll feel how important CSS is..
Thanks Rami and interesting analogy. I agree that once you master css you can be very powerful with it. From what I can see most people who argue against css simply haven’t taken the time to learn to master it.
I must respectfully disagree.
There are SOME layouts that to use entirely CSS requires an inordinate amount of extremely messy code to represent.
One example, is to have a banner across the top, a “side banner” down the left, with a background image that must align with the top banner in the corner, and then content within the area below the top banner and to the right of the side banner. In this case, it is almost impossible to get CSS only to render this as desired, either the width or the height of the side banner will be wrong, or the background image will appear to “disappear” or not be long enough, or be too long, or the content will bleed over into the side banner if you change the width of the browser. And all of this is absolutely hilarious when you attempt to make it work in multiple versions of IE and every other browser, let alone on an iPad or iPhone.
In theory, CSS is the answer, the problem is that the way browsers deal with SOME of it is not only not standardized, but can actually have the exact opposite result – for example position: absolute can cause a column to move to the left in one browser and cause it to move down in another, and cause it to move up in yet another.
I find that if I have to spend more than a 5 hours trying to figure out the combination of CSS statements to achieve the result I want on just one page, and I can do it in a table (a VERY SIMPLE table), in less than 15 minutes, then the dream of CSS has not been achieved yet.
I look forward to the day when a page renders the same way in all browsers for specific CSS statements. Second best would be to have a KNOWN set of definitions for how a browser brand will render a certain statement, then we can generate the css file according to what browser, but that’s a work around.
You can respectfully disagree, but I’m still going to say you’re wrong. Let me apologize in advance because what I’m about to say may come across as harsh.
There’s a huge error in logic in your argument. You make the assumption that because it takes you 5 hours to develop a layout in css that it’s the same for other people. That’s not the case. The limit isn’t the language, it’s your current skill level in using the language.
I speak English fluently. I’m lucky if I can still remember 50 words in Spanish. If I tired to reply to your comment in Spanish it would take me hours, even days, to put together a few coherent sentences. The conclusion isn’t that it takes a long time to communicate in Spanish. Spanish is a beautiful language that many people use to communicate quickly and effectively each and every day.
The conclusion is I don’t know the language well enough to communicate in it. The limiting factors isn’t the language, it’s my ability to use the language.
Same thing with the issue you’re having with css. The limiting factor isn’t the language itself, it’s your current skill with the language. That’s not meant as a knock against you. Right now it’s easier for you to code certain layouts with tables. Other people would find it just as easy to code the same layout with css.
I’m not suggesting it’s trivial to learn css, but it’s also not accurate to say the language itself is causing your specific layout issues.
I’ve linked to this article in a post as part of a project I’m doing on web design styles.
I agree with using divs and css to display content for what I think is a pretty simple reason – if I want to change the look of my site I can write a new style sheet using the same div IDs and the site is suddenly completely different. the ability to do this is what switched me from using the table-based layouts I was first taught. Even though browser compatibility is better (or supposed to be) with tables, the lack of flexibility when I inevitably changed my mind about the design meant I basically had to build the whole site again. Four-fifths of the way through an assessable project isn’t the best time to have to redo a table-based layout.
Thanks Emma. Appreciate it and I think this post being more recent is the more relevant one. As you can see I still strongly favor css layouts, but I think many of the arguments on either side of the debate get a little silly at times.
By the way I forgot to mention it when I commented on your post, but I did enjoy reading it.
I came to web design by way of VB. (Don’t laugh, my skills probably saved my job.) I had not heard about this controversy, being a WYSIWYG kind of guy. I will need to learn more about how to use cssdiv to do a page layout. Good Article and a lot of gold in these comments.
I promise I’m not laughing. We all came to web design in our own way and with our own skills. There’s nothing wrong with how you got here.
This debate is mainly from those who code by hand I would think. Early on you had to use tables to layout a site well. I think many people who spent the time learning how hold on to that knowledge instead of trying to learn the css way and in holding on to the known create arguments to defend their use of tables.
If you look at the source code of most sites (especially the ones you like) you’ll discover that most and nearly all use css for page layout.
I agree with what you are saying, however I think with the advancement of HTML 5, tables will start to disappear. The more professional sites are *usually* built using div/css scripting and now table cells as most sites require absolute positioned content which most sites are not using.
I agree that there will always be some people that cling on to tables, but I don’t think we will have to suffer too much for much longer,
Miles
People can build sites without using a table-based layout now and still do. I’m sure with html5 some people will be converted to using all css layouts, but I’m also sure many will still cling to tables as they do now.
“The best things in life are not necessarily easy or easy to learn. Not doing something because it takes time to learn is laziness.”
I have to disagree with this. Time is money. My old webpage is ugly (www.dragora.com) so I started to develop a new page (www.dragora.com/newindex1.asp). Both were done with tables. Granted, CSS loads faster and for big websites is easier to maintain for large websites, but after trying to convert the newindex1 page from tables to CSS, I’m having a very hard time understanding why CSS is better for small websites.
After a week of wandering around the interwebs I still can’t figure out, nor have I found any tutorials, on how to create a header like the one I have, one where there are three colums where the middle expands to fit a wider browser. Also, I’ve found no help in trying to figure out how to replicate the effect of a table layout where certain cells are merged. It’s true that the easiest way may not be the best way, but I don’t yet see that the benefits of CSS outweigh the much greater learning curve with regards to these more complex layouts.
You say that people apparently think tables are easier than css because they already know tables, but I think you’re wrong there. Tables seem, at least to me, to be much more intuitive.
I had my old table based page done in 1/10th the time that I’ve spent just trying to find some CSS code that accomplishes what my old header table did…and when I started it I knew NOTHING about tables.
I’ve seen a bunch of posts telling me that tables are the old way and other posts telling me tables are the “wrong way” for page layout, but have heard few good reasons why this is so, at least for small websites. I’m not trying to be political, but when Obama kept repeating change a hundred times a day during his campaign I questioned it because change is not the same as progress.
Likewise I seem to see a lot of likewise ambiguous clamoring about the change that CSS brings with little reason to change. Having done programming I understand reusability of code and the ease of making changes in one place for large websites, but this is little good with small sites.
Perhaps this is the reason this debate keeps going on, because this change doesn’t look like progress to a lot of people and they feel the benefits don’t really outweigh the intuitive design of tables that make design a lot easier for beginners. In addition there are the little seemingly obscure css properties that need to be inserted to make certain things function properly in general, or with older browsers.
If anyone would love to show me how to make my old newindex page into CSS I’d appreciate the help, but I have to admit that lack of documentation for anything other than simple layouts is getting really frustrating.
Mark your site would be very easy to code with a css layout. I’d have to see the css you’re using to understand why you’re having problems. Feel free to email me if you want. It’ll probably be a week or two before I have the time to really look, but if you email me the code I will look.
As far as it being easier for you to code it with a table now, that’s probably true. I do understand your point. The thing is, it’s not easier because you’re using tables. It’s easier because you’re more familiar with using tables. Odds are you’re finding css hard, because you’re trying to make it behave as tables do. It’s pretty common to do when first learning css.
Your layout is really one that’s pretty easy to code. You don’t need 3 columns in your header. All you really need to do float the customer service phone number and search form to the right. Your logo image can either be a background image on the header div that’s not repeated or a regular image inside the div.
The phone number and search can either be wrapped together in another div that’s floated to the right or they could each be floated to the right independently.
It’s really about 5 -10 minutes work to set up. Feel free to email me and if you don’t mind waiting a bit I’ll be happy to help.
I’m really struggling with whether to learn and use CSS for layout. I’ve been a designer for over 20 years and been using tables for layout for 13 years. Most of the sites I create are for small businesses averaging around 10 – 60 pages. (10-20 is most common.) I really like using CSS for formatting text, lists, positioning, etc. In my opinion, combining table layout with CSS works great. I’ve read the debates. I’m not questioning the benefits of CSS in general. I use it and love it. What I’m trying to figure out is the benefits in using CSS for LAYOUT. Here are my questions…
CSS Layout Advantages:
1) Easier Site-Wide Changes – CSS proponents claim site-wide changes are easier with CSS because you change one file and boom, it changes on all pages. I use Dreamweaver template files. I make a change to the template file and boom, it changes on all pages. What’s the difference?
2) Faster Load Times Because of Lighter Code – I remember load times being a major issue when I first got started but it doesn’t seem to be the case anymore with so few people on dialup. I can’t tell any discernable speed difference between a table layout and a CSS layout’s load time. (Yes, I like clean code too.) Heavy image use and Flash still seem to be the biggest factors in speed. If the human eye can’t tell any difference, then what’s the point? And server space/bandwidth doesn’t seem to be an issue anymore either. Space on the server for all of my client’s sites is generally 1/16 of capacity.
3) SEO – From what I can tell, search engines aren’t indexing or ranking CSS layouts higher than table layouts. The algorithms used for ranking most often are content and inbound links. The spiders are highly efficient at discerning code from content. So what difference does it make?
4) Separation of Style and Content – I guess this one is related #1, ease of updating? This is what Dreamweaver template files do. It separates style from content (editable/un-editable). I don’t know about you, but generally speaking what my clients want most often is to update the content. I don’t understand why it would be easier to update content using CSS more so than tables. (Remember, I DO use CSS for formatting.) If they want to tweak something in the design, again, piece of cake to do. Just change the template file. It’s not hard.
5) Greater Consistency – If you use template files and CSS, where is there inconsistency?
Disadvantages to using CSS for layout
1) Inconsistent Browser Support – Different browsers will render CSS layout differently as a result of browser bugs or lack of support for various CSS features. This is no small drawback!! It’s huge. I fought this very same battle using tables back in the 90s. Different browsers rendered the design differently. I really resented (and it sounds like many of you do too) all the time I had to spend to get a site to look as it was intended for ALL users. I REALLY don’t have any desire to fight that battle again. I know there are workarounds. But again, if I don’t see the overwhelming benefits, I won’t don my armor or sharpen my weapons.
My questions and concerns are genuine and not an effort to get CSS lovers to defend themselves. If you are designing using CSS for layout, cool! You are a part of an ever growing majority. Personally, if I could instantly convert a design into HTML, I’d do it. I have no great love for code. Right or wrong, I LOVE spending most of my time designing. The rest is a necessary evil to get the design into the medium. So if you feel strong emotions regarding CSS layout, don’t respond. 🙂 If you get where I’m coming from, please help me understand using logic.
Jennifer
Hi Jennifer. Don’t worry I’m not taking your questions as a need to defend css. I think you’re asking legitimate questions and I’ll do my best to answer.
1. Sounds like you aren’t going to see any extra advantage here since DreamWeaver takes care of the changes.
2. Load time is always going to be an issue. Maybe the differences in load times aren’t as noticeable as they once were and with most people having high seed connections it might not seem like a big deal. However…
Google is now using load times as a factor for ranking and no matter how fast your site loads if it’s slower than the next one it’s going to be perceived as slow. Personally I think until we get to the point where we can load a page before someone finishes clicking the link to that page there’s room to improve.
3. I agree with you about seo. I don’t think using css for a layout means the page automatically ranks better. I don’t think search engines really care if you use tables or css for the layout. They’re interested in your content.
Of course see load times above which now seem to be one signal Google looks at.
4. Separate of style and structure is less about whether or not you use css or tables. It’s more about making sure your code for structuring the page and your code for styling that structure aren’t woven too tightly together. This would be more about inline css or using html attributes like the font tag vs a separate stylesheet
You can separate style and structure with both css and tables.
5. Again DreamWeaver is taking care of this for you.
As for your disadvantage I have to disagree. Browser support for most of css is as consistent as it is for tables. There’s really not a lot of css needed for layout. Much of using css for layout is realizing that you don’t need to do as much as you think. When people are having trouble getting a css layout to look the same across browsers it’s usually more to do with the skills of the designer than with css itself.
When I first started using css for layout I couldn’t always get things to look the same, but most of it was me. Now I barely have to test my layouts in multiple browsers because I’ve learned how to keep them consistent across browsers. It takes some practice, but it’s really much easier than you might think.
For me this debate is less css vs tables as it is divs vs tables. Tables and divs are the structure. With that in mind I prefer divs.
1. They use less code. I show this above in the post. There’s simply less code to create a div than there is a table with a row and cell. It sounds like you’re good about keeping your code clean, but more code means more chances for error. It doesn’t mean you’ll make the error, but more chances exist.
2. Divs are more flexible. Table cells are dependent on the table, and the rows and other cells in the table. A div is its own entity. I think making your structural elements independent is the better option. I think it makes them easier to move them around on a single page.
Not so much about being able to have your changes update across the site, but on the single page itself. Divs are like blocks that stick together when near each other, but with a little pull you can separate them and do something else with them. Tables are like having the blocks bolted together and needing all blocks to be bolted before the structure itself holds together.
3. They’re quicker to load which I mentioned above.
I hope that helps answer some of the questions. I can’t and won’t tell you that you have to abandon tables. What I will say though is that every person I’ve ever met who was equally capable at using both css and tables chooses to use css. That should tell you something.
I have used table-based layouts for a few years and have started using css to mainly style text. I have tried to learn css with online tutoring (lynda.com, http://www.w3schools.com/w3c/w3c_css.asp, etc.) which is all fine and helpful. However, laying out an entire web page in css is what I want to learn (using divs) and I can’t seem to find an online tutorial specifically for that. Maybe I just haven’t searched the web enough.
Can you recommend several online tutorials on how to lay out a web page with divs, as well as with their accompanying css rule elements?
First I’m glad to see you making the switch. Learning to layout an entire site with divs and css is the hardest part, but I promise it’ll be worth it.
A few years ago I wrote a post on how to create a 2 column layout with css. The post right after shows a 3 column layout. I code both a little differently now, but the posts might still help.
I learned by reading the book Eric Meyer on CSS. He takes a layout done in tables and works to change it to divs and css. I typed along with all the code samples and it helped me a lot.
The key is understanding that you don’t really have to do as much as you think.
I wrote a 2 part tutorial on turning design image into a css layout for another site. The posts aren’t just about the code, but I do provide the basic html and css I use now for a 3 column layout.
How to Turn a Design Image Into a Working Web Page: Part 1
How to Turn a Design Image Into a Working Web Page: Part 2
Also anytime you come across a site with a layout you like copy the source code and when you have time study it to see if you can understand how they did what they did. It’s a great way to learn.
Thanks for the online references, Steven. I will use them to learn more about CSS.
My biggest concern is if I can design the following website designs in CSS. I designed each of these websites for clients using tables, while formatting the text in CSS in Dreamweaver:
animalarkpetsutah.com
taylor-graphics.net
biscotools.com
I have an unorthodox, perhaps unstandardized approach to web design. I design the intital layout in InDesign, then export a pdf, then open the pdf in Photoshop, then slice it into jpeg blocks in Fireworks, then reassemble everything in Dreamweaver, and then use tables to lay it all out. Then I format the text in CSS adding padding and margins where needed. I’m still using the spacer.gif to tweak spacing.
I feel like I’m at a confessional since most web designers don’t do it this way, but my designs image heavy and clients have been very pleased with my work. Unfortunately, by using tables I think increased load time and perhaps SEO unfriendliness of my code are stumbling blocks to my future success as a web designer.
I’ve been told I can create any design feasible with CSS, so I have offered the above URLs as examples you can either confirm or be dubious about relative to their successful conversion to CSS from tables.
Thanks very much!
John all 3 of the sites you list can definitely be developed using css for the layout instead of tables.
Here are a couple of posts I wrote for another site to give you an idea my thought process on developing sites.
How to Turn a Design Image Into a Working Web Page: Part 1
How to Turn a Design Image Into a Working Web Page: Part 2
Hopefully they can point you in the right direction with your own designs.
This is rubbish. As a web designer I spend the vast majority of my css time finding work around for IE and sometimes other browsers. I can bring myself to use tables, but css severly restricts my deisgns because of cross-browser compatibility.
Also if you include the wrapper tags and the like you tend to end up with more tags for css than tables beause of all the work arounds you have to do.
No it’s not rubbish. If you’re having to spend the vast majority of your time finding workarounds for IE then you’ve probably been doing something wrong. I hardly ever have to write more than a few lines of code specific to IE. Much of the time I don’t have to write anything specific for IE.
CSS doesn’t restrict anything. It doesn’t lead to the need for more tags and it doesn’t require workarounds. While you probably won’t appreciate hearing this, the more likely cause for the problems you see is your own knowledge of css.
Web designers who take the time to learn css don’t have the same problems you’re seeing. Don’t blame the language. Take the time to learn how to use it.
One thing I’ve noticed in your tutorials is that your not very accurate with alignment. If I throw out a website which has no padding or un symetrial or miss-aligned text I would be asked to start over. Your tutorials are really only half-done and stop at the parts where css begins breaks down.
Where exactly are my tutorials not accurate? Unless you offer specifics I’m going to assume you’re just name calling, because you were unhappy with my previous comment.
This post isn’t a tutorial so I would need to know which one or ones you’re referring to as well.
Is it possible that there are errors in my tutorials? Sure. If you were to point one out to me I’d either fix it or explain why it might not be working for you and probably even help you make it work.
As far as I know I’ve never provided 100% of the code to any of the sites you’ve developed, which would mean the issue isn’t necessarily my code. it could also be your own code or more likely that your code and my code aren’t working well other. A square peg and a round hole can both be perfect examples of each and yet not work well together.
That you had a problems on a site you were developing doesn’t mean my tutorials aren’t accurate. They seem to work quite well for many people who aren’t you.
By the way if something you followed here didn’t work for you, you could have chosen to ask me if I’d help figure out why and I likely would have.
Instead you chose to insult me and the tutorials here. Not exactly the kind of thing that’s going to make me want to help you/
If you’re so convinced tables are better than css then go ahead and use tables. It’s not going to bother me at all.
I never said I prefur tables. Incidentially you do provide 100% of the code because you show it in your examples, in the source. Your probably right about round pegs and square holes, and I am sorry if you took offence, but the fact that countless people have these issues with css must indicate a lack of continuety with css.
I don’t want to use tables but I’m finding it harder and harder to justify not using them. Especially when php can make up for some of the down falls.
One issue is that different browsers have different deffinitions of the padding and the margin variables. The fact that different browsers and different versions of browsers look at these and other variables differently is a really pain.
Chris your first comment seemed to indicate you preferred tables over css. If I misinterpreted that I apologize. And if I gave offense at all as well I also apologize. It wasn’t my intention.
I still don’t know specifically which tutorials you mean, but I don’t think I’ve written a tutorial that offered the complete code for a website. I’ve offered tutorials on the basic layout and I’ve offered tutorials on things that can go inside that layout, but never all the code for an entire site. If there is a specific tutorial that isn’t working for you just let me know which one and I’ll be happy to take a look to see if there are any errors.
As far as other people having the same issues with css, I do agree that happens. What I’m saying though is the problem isn’t css itself. There are many more people who don’t have those problems. When I first started learning css I did run into problems making things work cross browser. The issue though was how I was using css and not css itself. As I learned more I stopped having those problems.
With browsers having different defaults paddings, etc. it is a pain, but there’s an easy solution, which is simply to declare the padding or margin, etc. The defaults only come into play if you don’t specifically tell the browser what to use.
You can either explicitly set the values when browsers are behaving differently or use a css reset file like the ones from Eric Meyer or Yahoo. The reset files basically set many things back to 0.
Once you specifically set the bottom padding of a paragraph to say 20px, all browsers will give paragraphs a 20px bottom padding. It’s only when you don’t specify the value that browsers might use different defaults.
5-1-11
Hi Steven,
I find your posts very educational.
I have designed the following sample homepage for a client:
http://www.taylor-graphics.net/eye_clinic/
The links are just placeholders for now.
I have used some CSS to style the text, but not the design.
Is there a way I can pay someone to turn this same homepage design into a total CSS design? And, then I can see what they’ve done with the code as far as CSS goes.
I’ve been studying the Eric Meyer CSS books, so I am picking up CSS quickly.
I’m still a little inexperienced to style the whole design in CSS, though.
The form on the bottom left of the homepage is an html feedback form through http://www.freedback.com. I have a business subscription with them.
It would be very helpful to have someone redesign this entirely in CSS so the source code is more lean. Then, I can see how they styled it in the source code.
Could you do this?
Thanks. You can call me if you want.
John Taylor
Taylor Graphics, LLC
(801) 636-5158
Sorry I didn’t reply sooner John. You can definitely hire someone to create a template for the site if you want. I’ve done that for people before. You’re welcome to send me an email of fill out the contact form and we can talk.
However if you don’t need this right away I am planning a post on setting up a 2 column layout with css in the next couple of weeks.
Eric Meyer’s books are good. I learned through them. Using css to layout a site is the most difficult part, but it does come together with a little practice.
Feel free to contact me if you want me to develop the home page without tables. It won’t take long to set up for you, though I naturally have to charge for the work.
Here is the CSS code, so far, through Dreamweaver:
http://www.taylor-graphics.net/eye_clinic/css/index.css
I have used css and divs to create multiple lists for a table structure with four side by side columns. And I never use some software package to do it for me unless I wrote that package myself.
The problems I run into are on updates: adding a few lines here, and changing the text there. This forces me to go and adjust the width and height and modify margins and padding in EACH div. What happens if it goes 1 pixel beyond the the available size? The whole display gets shuffled. Then there is hours of adjust here, adjust there, view, adjust …. and on.
And then discover that I forgot a somewhere and nothing lines up with the adjacent cells.
I think, though I haven’t used them in years, that tables are far superior for site maintenance in that you do not have to adjust sizes, just add or take away a table cell.
John if you’re having to adjust margins and paddings and height and width because you’re updating text you’ve done something wrong when setting up the code. Your text should reflow with changes. You have to be writing code telling specifically telling them not to reflow.
Generally you wouldn’t be setting heights on most divs allowing them to expand and contract based on the text. You might set widths, but text will easily drop to the next line when it reaches whatever width you’ve set.
Outside of some special occasions you should never have to resize a div or it’s margin and padding because you updated the text inside of it.
The places where this occurs has problems with that flow. It is in lists of links in one column and descriptions in another column, with more data in a third or forth column. These must all be on the same horizontal line to work, and if one has a word or two text change, only that column will “flow” properly, and I have to do lots of editing of the other columns.
Tables will self adjust to keep the lines aligned.
What css function does that?
Do I have to have a separate div for each line? Even that doesn’t work when they are not all exactly the same font size with no “flow”
That flow is what needs to be eliminated!
Could you send me a link to the page? Everything should be able to reflow the way you want with css. I’m thinking something in the way the code was set up is preventing that from happening.
It might not be that one line of css is off, but more that the way that part of the page is structured in general could be done differently.
If you send me a link I’ll be happy to take a look. It might be a few days before I can get to it, but I will take a look.
Divs cant do what tables can as simple as that. Columns of equal height? Can’t be done, we have faux columns but that’s really just ‘green screen trickery’ in doing so.
This is one of the reasons why there are people who prefer tables instead of using this kind of ‘trickery’ and ‘black magic’ to fake the appearance of what tables can do without all the extreme measures.
An example of this lie is what proponents of divs like to show off by only having a few divs compared to a table structure, but in order to get even close to having the same properties as table we have to use something like the last example in http://www.vanseodesign.com/css/equal-height-columns/ as the others are just faking the appearance with a background image. But now not only is the solution more convoluted with containers i.e the complexity in code grows proportionally with the amount of columns compared to a simple table but we still dont really have equal length columns as it’s only the containers that are equal length and not the content/sidebar divs themselves.
This is why divs aren’t superior for layout coz they cant even do what tables do out-of-the-box even with all the complicated different solutions people have invented to try and get close. After-all the 3 column layout with equal height is referred to as the holy-grail in css, enough said!
As for the ‘I dont need any extra code to get stuff to work for ie when using divs and css’, really is that so? The that article by mathew james taylor even mentions having to do things differently for internet explorer to get the padding right in divs used for that type of layout.
No one is saying that a div can do more than a table. You have to look at the bigger picture instead of focusing in on one aspect of that picture.
The argument isn’t what a div can do vs what a table can do. The argument is about how to structure a web page.
With equal column heights, yes it’s easier to create them with tables than with divs alone, though if you look at the last of the 4 methods I described you’ll see it’s not hard to create them with divs and css and it still uses less code than using tables.
Just because tables make one thing easier doesn’t make them better than divs and css overall. And I’d suggest it’s still debatable that tables do equal columns better. There are plenty of easy ways to create equal height columns in css.
And yes it is true that you don’t much need extra code to get things to work for IE. If you know what you’re doing you might need a few lines of css total to fix IE bugs. It still ends up being less code than you would use for a similar table based design. Still it’s hardly the fault of css that IE has bugs.
On one hand you say you can create 3 columns of equal heights with divs, but in your blog post, you mentioned that people shouldn’t try to make tables with divs.
What’s the deal? Tables/grids (the shape) are the holy grail of layouts. To me, it’s the most pleasing layout shape. Newspapers have figured out this ideal layout a long time ago, and have thus named their writers “columnists”. They aren’t called floating blockists. Sometimes they write for things called “tabloids”, or articles of paragraphs arranged in tabular form. The columns of a newspaper are used to guide the reader along the layout. This is the same when using divs. The order and nesting of the divs matters. The fact that order matters even with divs invalidates a lot of the arguments table haters constantly throw out, but considering we’re trying to layout documents in the first place, it makes sense that order matters, otherwise the whole semantics argument would be totally out the window too! It totally contradicts the argument that you can completely change the layout with only css, as if you’d want to put one item before another. Order in a document is semantically relevant to the document to begin with.
Laying information out this way is simply more intuitive than floating divs, not from a web standards perspective, but from a “kid puts shapes in the holes” perspective. The whole semantics argument is nonsense. If table tags were called tags, nobody would be complaining, and there would be no ongoing debate. Using display: table-cell would work fine now that everyone uses IE8 or over, but the floating div folks insist on emulating a grid with floating blocks anyway.
You also keep pointing out how everyone who disagrees needs to keep learning, but if you’ve ever been in a large production environment, you’d realize that this is a complete load of bullshit. All the “pro-css” designers I’ve ever worked with have tended to be full of shit, constantly creating new display bugs in production. Sure you can say they just need to learn more, but sorry, they didn’t. My guess as to why they didn’t learn it as well as you is because it’s actually not intuitive as you say, especially when trying to implement a grid shape with 3 independent blocks. Like others have pointed out, fixing display bugs related to just about any css based layout often takes entire release cycles, just to get ruined even more by some other dopy designer.
You also made my exact point as to where tables shine the most, and it has nothing to do with semantics. You pointed out that table cells don’t work independently. Tables should be used when a bunch of blocks need to depend on each other, like maintain the same height, or to cooperate in filling their parent’s width.
Calm down. I’m not sure who angered you so much, but please don’t take it out on me. I never broke any of your layouts or created display bugs in whatever you produced.
Where did I say you shouldn’t try to make tables with divs?
Tables and grids are not the same thing in web development. I think grids are great, but I don’t think you should create them using html tables for the reasons I mentioned in this post.
Like I said the debate the won’t die. I’m amazed that in 2013 people are still defending table-based layouts, but whatever.
The reason people are still defending table based layouts is because tables are the correct SHAPE for most client specifications, not independent blocks floated to the left, or independent blocks with absolute positioning or independent blocks using any other trick to make them seem like they cooperate. Table cells cooperate very well with each other, the way everyone expects things works. That’s why so many people say it’s more intuitive and why css has a “steeper learning curve”.
And here’s what I’m referring to you saying in your post:
“The problem most people have when learning to use divs is trying to force them to act like tables instead of allowing them to be what they are.”
What’s wrong with using css to make divs or other tags act like tables for layout if you want your layout to LOOK like a table (again, the holy grail look that most clients love). For some reason this is frowned upon as well. To suggest that the purpose of divs is to use block rendering contradicts the argument that tags should have semantic meaning and not display meaning. Why does it matter how divs are rendered as long as the document written with strong conventions and good semantics?
The times when floating blocks are more appropriate to use, besides it’s original intended use of having text wrap around images, is specifically when the blocks are meant to be independent from one another.
A horizontal list can go either way depending on what the client wants. Sometimes they want the elements in the list to cooperate to fill the container while sometimes they want the width of each element to be dependent on the content of those individual elements.
There’s really no reason in my opinion to use floats on a horizontal list when the goal is to have the list elements cooperate rather than be independent blocks whose widths are determined by content and padding. I also believe the opposite, there’s no point using table rendering if you DO want them to be independent.
Believe me, I’m not making the argument for convoluted nested tables with colspan settings, etc, nor am I arguing against semantically correct documents. When I do use tables for layout, it’s often a 1 row table with 2 columns, and it’s because there were no semantically correct tags that use the correct rendering that would work for IE6. Times have changed. Hopefully people will start accepting table-cell or something similar. I honestly don’t care what they call it.. as long as it still works like tables.
I avoid tables and table-cell in almost all layouts to avoid ridicule, but deep down I truly believe that anything else is convoluted and meant to create more jobs for web developers.
I don’t think the choice is about shape though. You can create the same shape in a number of ways. Again I do agree that grid shape is a good one. It’s more in how you code it where I don’t think html tables are the right approach.
Let me also add I’m talking about using tables and nested tables for the entire layout of a site. I’m not suggesting you should never use an html table anywhere. They make a lot of sense for displaying things like data. I also don’t have an issue if you want to use them to display a list of links in a menu.
What I’m saying is the entirety of your layout shouldn’t be one table inside another inside another. Tables can be part of your layout, but they shouldn’t make up the entire layout.
When I said forcing divs to act like tables I don’t mean you can’t arrange them in a way that looks something like a table. The problem is people looked at divs and just mimicked what you could do with a table cell. Divs can do some things table cells can’t and they can’t do some things well that table cells can do easily. My point was they aren’t the same thing and so to learn how to use divs you should learn the strengths and weaknesses of divs and not try to force the strengths and weaknesses of tables and table cells on them.
It sounds like you’re using tables the same way I’m suggesting is fine. Sorry if it came across like I was against tables completely. Just for the entirety of your layout.
With the 4 methods you’ve got the only that really comes close is the last & it requires more code. Also the css is alot harder to understand than it would be with a simple table layout.
I’m not trying to say that tables are better, but this whole css and divs are better is wrong imo, it’s about using the right tool for the right job, divs are good for block layout designs it’s what they do best, whereas tables are better for column type layouts.
Getting back to IE, the 3rd method you used with negative margins comes close but once again special considerations need to be taken with IE for this design, and yeah it’s not the fault of css but IE, however when the majority of your target audience maybe using this browser it’s important it works properly hence the use of tables which may result in more ugly looking code unfortunately but it is just one of the requirements until microsoft clean their act up.
Lastly I’d like to say that I dont think problem is with tables or divs, but what html has to offer, there isn’t really anything specific for that type of design, tables weren’t meant to be used for layout but data instead, there hasn’t been anything until now with css3 and css3-grid positioning perhaps http://www.w3.org/TR/css3-grid/. It looks promising and hopefully will be the way forward from now on, getting rid of both the ugly table and div mess once and for all 🙂 I’d be interested to know what you think of it.
Fair points and thanks for making this an intelligent conversation. This topic often leads to discussions that aren’t this thought out.
It could be because of my familiarity with css, but I don’t think the last method is hard to understand. For a complete newbie I would agree tables are easier to understand though tables do trip a lot of newbies up too. I watched many people struggle when it comes to nesting tables. Not something you need for a two column layout of course.
I disagree about it being more code. If anything I think the code would be almost equal and the differences insignificant. At most the html would require a single class or id extra.
I think there are appropriate uses for tables, but I don’t think the overall layout of a page is one of those appropriate uses. I won’t restate all the reasons why since I said them in the post already.
True. If your visitors are using IE you need to support IE and whether it’s the code or the browser that gets things wrong is irrelevant. I don’t, however agree that the only way to make things work for IE is tables or even that it’s easier. You can make css work with IE and it really isn’t hard. IE gets some things wrong, but it gets a lot more things right. I think it gets an unfair rap sometimes.
Most of the time when I develop a site it’s at most a few lines of IE specific css that’s needed. By a few I mean less than 5. It’s usually one or two things that may cause a problem and those problems are easily fixed. Tables to me make for a more complicated structure that often create even more problems. Of course that depends on the developer more than the code itself.
With the 4 methods if it’s important to a site to support older versions of IE then sure don’t choose the method which might not work with those versions. That’s why there’s more than one method in the post. There are also dozens of other methods I didn’t mention.
I agree with you about css3-grids. I’ve looked at the page you linked to before and have it bookmarked. I also think it looks promising. It’ll be interesting to see how it develops and also what kind of browser support it gets.
We’re not quite there yet with what we’d like to do where design is concerned. Oddly as grids become more and more in use they’re sometimes developed in a way that attempts to recreate a table using css. Kind of ironic.
I do understand the appeal of tables. Where layout is concerned though, I think the cons of using tables outweigh the pros and so favor using css.
Nah, i disagree.. if i’m the only one who’s going to work with the site, i go for tables, it’s 1000x faster and easier to get a decent layout.
but i do straight apps, nothing pretty.. data-driven stuff…. any pretty crap i use css on those parts alone.
In other words you haven’t taken the time to learn how to layout a site with css. Tables are simply not faster to create. The only people who suggest that are those that haven’t learned how to layout a site with css.
Haters.
There is nothing wrong using CSS and Tables. If tables confuse you, I think you are a lost soul.
I could create tables just as fast as anyone with css, if you’re not using some noob program like dream weaver. Notepad is for pro’s. The only way it’s faster is for updating, but if you read correctly, I style my tables with CSS tags (div, id, class) so I am just as quick. I try making 100% css layouts and they never are cross browser effective, so I resort back to tables and I never have issues. May be my knowledge, however tables work great!
Tables are not effective by themselves anymore I agree, it takes a lot of time updating thing manually, so CSS is a BIG help. It makes updating global and quicker. But using tables and styling them completely with CSS is just as effective as CSS alone.
If I ever learn CSS completely, I’ll use it more often as you can’t fight progress but I’ll never discount tables from the equation.
“If I ever learn CSS completely”
Thank you for proving my point.
I coded up 3 different versions of the same page (divs, tables, tables with table-layout:fixed), and then ran some benchmarks on performance and file sizes.
The performance claims I’ve read about here and elsewhere on the web for divs over tables are over-hyped – I found only a 10 ms advantage for the div technique over the table technique. My div test page was only 2285 bytes smaller then my table page which would save me 1.74 MB/month of data transfer. If you have a high volume site, it might be a good reason to consider using divs. Here is a link to an article with more detail
I didn’t make any specific performance claims here other than faster, which you apparently proved. As networks improve the speed advantage becomes less meaningful and for a small site it’s not going to be a big deal either.
However, I don’t think that’s the main reason to choose a css layout over a table-based layout.
The greater flexibility you can create with your structure and the maintenance advantages are the more important reasons.
A 10 MS difference is meaningless. If I had stopped my study on the first day the table would have “won” – by an equally small margin. I can’t go selling a 10 MS speed advantage to anyone and expect them to take me seriously.
I think your comments re flexibility and structure have merit assuming the only tools available are html and css. However there are other methods to abstract changes that need to be applied to more then one file into a single file. .Net has master pages and user controls which are ideal for repeating blocks of code. Your 2-column layout example could easily be accomplished with a .Net master page. Even a simple html site can utilize include files for repeating blocks of markup.
I’ll reserve judgment on maintenance but I have a hunch I’ll be able to go in and make the same changes equally as quickly whether I start with the div or table test pages. Maybe I’ll apply changes to my test pages as my home page changes and track the time involved.
BTW why “css layout over table layout”? Both my table and div layouts use css equally.
Again all I said was faster in this post and 10ms is still faster. You said I made overhyped performance claims, which I didn’t
Also I said speed isn’t the main reason for choosing a css layout over a table-based layout.
The flexibility is in your html structure. It has nothing to do with other tools. When you create a table structure in html it displays a table and your content is wholly dependent on the source order of the code. The same isn’t true if you’re using divs.
Why css layout over table layout? Did you read the post? I wrote it to answer the question.
If you want to use tables go ahead. I’m not going to stop you. However, know that the industry has moved on. Years ago it moved away from tables and towards divs and css for layout. The industry is now moving again toward a responsive design workflow.
Out of curiosity can you offer an advantage of table-based layout over divs and css? Proving that the css layout loads 10ms faster (20ms when I just ran the test on your site) doesn’t exactly endorse using tables instead? It only suggests that the difference in load time isn’t a lot per page. How does it suggest we should use tables?
IMO, performance claims made in the absence of benchmark testing are the definition of hype. I’ve seen these performance claims for div over table all over the web, and many of them assert “much faster”, rather then simply “faster”. Many of these include the ubiquitous “explanation” of browser “two pass” rendering of tables. C’mon man! Odds are pretty good that none of the people who wrote these posts are or were on the development teams that wrote the browser code. And that, in my view, should be the only thing that qualifies you to comment on the number of passes the browser makes when rendering a page.
Regarding flexibility, I can see your point about how divs/css can make it possible to flip columns around by only making changes to a css file, and have those changes propagate to many files. My point is that there are other ways to achieve this benefit. In my scenario, I flip the first and second td elements in a .Net master page. It will work equally as well, and only take seconds to accomplish. I agree that you’ve made a case for flexibility, but I don’t think your post demonstrates that divs/css are the best way to attain this flexibility. I believe What’s best in a given scenario depends mostly on the skill set of the person doing the job. But I guess when all you have lying around is a hammer then every problem looks like a nail.
I thought my question “BTW why ‘css layout over table layout'” was clear from the context but apparently not. So I’ll be more explicit. My question to you is “Why frame this debate in terms
of ‘CSS vs tables’ when it is clear that one can can use CSS techniques with respect to tables as well as divs?” To me, framing the debate this way is yet another attempt to make a distinction
between the 2 techniques when in truth, there is little distinction to be made. Another example of hype at its finest.
LOL, I’m not advocating tables b/c they are infintesimally slower then divs.
I don’t offer any advantage per se, on tables over divs. I do have a very fast development process which involves slicing an image file from my designer, using a tool called Image Splitter. The tool emits old school attribute heavy html tables but I wrote a little javascript parser that seperates things out into clean html and css. The resulting code runs issue free cross browser.
This process allows me to offer fixed price websites without a lot of risk that I’m going to have to eat a lot of hours resolving cross browser compatibility issues. That’s not an argument for tables in general, but it is an argument for me to continue to use tables for my small business clients who won’t pay a lot for a web site, and will not get enough traffic to benefit from div based techniques. I do think there is an advantage for div based techniques for high traffic sites and I will continue to expand my knowledge of div based layouts for this reason.
No matter how many times I see this question or people making an argument on behalf of their opinion, the technical answer remains the same. The “best practices” standard for doing web design is to use DIVs for page structure and tables for tabular data only. Not all browsers (especially older versions) render tables the same. CSS is a standard across the board.
Justin, apparently I named this post well, since the debate never seems to die. I’m amazed people still argue in favor of table-based layout.
@Dave – I think we’re getting squished with the replies to each other so I’m starting a new comment.
I still don’t see where I’m hyping anything. I didn’t say things like css is much faster or place any other qualifier on it. I just said they were faster, which you proved. It sounds like I’m being lumped in with other people who are making grand claims. There are many things you can say I do, but hype isn’t one of them.
My point about flexibility isn’t simply flipping columns. HTML tables impose a more rigid structure on the content than a div. A div is a more generic container that doesn’t impose any structure on the content within. A table does.
My bad on missing the context of your statement. This post is framed the way it is, because it’s a reaction to posts framing the topic as html tables are better than css. I didn’t create the overall frame to the conversation. I’m simply adding another piece to it.
I disagree with you that both are techniques with little distinction. That’s why I wrote this post.
I’m glad your process works for you, but that doesn’t change my opinion. My process doesn’t involve spending hours resolving cross-browser compatibility issues by the way. That’s actually where the hype is. I’m not sure why people think it takes a lot of time to get things working cross browser. It doesn’t once you know the one or two places where there could be an issue.
css vs tables WRONG! divs vs tables RIGHT!
designing since 1999 started with dreamweaver, handcoding is a pain and for programmers.
divs are also a pain
Some content here
and
Some content here
ooh tables are so complex, check out the css for that div when its all done
and how painful it is just to align a freakin div on the middle of a page, align text with a image?
users dont give a about codes im all in it for the designs
Out of curiosity did you read the post? I did say calling this css vs tables isn’t really correct and that it’s really about tables and divs. Your comment suggests your commenting on the title of this post and not the content of the post.
You’re mainly proving my point that those who argue in favor of tables usually haven’t spent the time to learn to use block level elements like divs and css well. When you say things like hand coding is a pain it suggests you haven’t taken the time to learn css well. Learning how to use Dreamweaver is not the same as learning to write the code.
I totally thought this debate was long dead, but hid a road block and was procrastinating so I thought I would google random stuff and found this. Very amusing.
I thought the debate was or should have been dead a few years ago. Yet every few months someone else pops in here to tell me why I’m clueless and to argue in favor of table-based layout.
I guess the title of the post was apt.
Fantastic read.
I developed a few personal websites back in 1999 and used tables throughout them all. Over the past few years I’ve been slowly converting them to divs and CSS. It was difficult (and very confusing) at the start, but I’m now completely clear on why it’s a better approach.
Thanks Craig. I think your experience is similar to what most people who’ve made the transition from tables to css go through. At first it’s confusing since it’s such a different approach, but once you make it through the learning curve it’s obvious that the div/css combination is a much better and more flexible approach to building sites.
There are some new things on the way with css3 too that will make working with divs/css even easier and more flexible.
OK,this is total madness.I have 3 reasons,ready reasons,as to why tables are better than divs.And more,but not on the top of my head.
1)Flexible?No.Tables are much more flexible due to fixed positions.Yes,fixed positions.You just have to set the positions and hey presto!Your site as you want it!
2)Less code?No.Comparably,table-based websites are having much less lines of code to write.Because,you are also writing the CSS,and it’s always not one file.So,code is much much less.
3)Stop using Dreamweaver to code websites for God’s sake.Give .NET websites (Aspx) a try,you will be amazed.And,for what you want to be shown in all,you just do a master page.Plus,divs are NOT cross-resolution.You have to add fixed dimensions everywhere,and positions screw up in mobile resolutions.
1. Really? Fixed positions make things more flexible? I think not.
2. Yes you use less code using divs than tables. Read the post to find out why.
3. I don’t use DreamWeaver and you don’t need to add fixed dimensions everywhere to make divs work.
Nothing you said is true and most of it doesn’t make any sense. In fact your reply only makes it clear you don’t know to build sites using divs and css.
I’ve been doing web design since the beginning of the internet as a hobby and now professionally and I like a combination of both worlds. Whatever works to get the job done you know? Who cares, as long as it looks good on all the browsers and search engines are picking it up. Anyway, the real reason I wanted to comment here is because I think it is hilarious that I’ve been reading people bashing table layouts and saying they can’t stand any website that uses tables, then I view the source code and they are commenting on a page that uses tables! Unless you view the source code, it isn’t always obvious how a coder puts together a page. Why does anyone really care how something is put together? The only time I get nosy is if someone did something mind blowing that I want to learn how to do also. Otherwise, I just appreciate when someone makes the website function well enough for me to get to the content I’m looking for. This site is simple and fantastic, thanks for making it easy to read your content.
At least my code doesn’t use tables for the site layout. 🙂
I hope I wasn’t coming across as bashing tables. I think tables were a great way to layout a website once upon a time. I just think css is a better way now for the reasons mentioned in the post.
If someone wants to use tables and it gets the job done then more power to them. My goal wasn’t to bash tables, but to point out why I think css is the better approach to layout.
Thanks for the compliments on the site.
Nice post. Even though I like tables I appreciate it when someone with a different opinion can use ‘humble’ language to support his case. Thanks!
Well, today a few colleagues of mine got freaked out when they saw me using a table to display “data”. I believe many developers only read “do not use tables”, missing the later half of the sentence “for layouts”.
Developers need to realize that it’s okay to use tables when you have to display data and you need to use divs when you have to create layouts. Replacing one with the other will lead to unnecessary complication
Wow. That’s crazy. What were you supposed to use? A list? A paragraph? I think you’re right about people reading do not use tables and missing the part about layouts.
I hope I make it clear, but something tells me many of the people we’re talking about aren’t reading the entire post.
Nice article. I agree your point of view. I hope this will show some good ways to the others. Thanks for this.
I really like your saying “Not doing something because it takes time to learn is laziness”.
“Tables should only be used to display tabular data” but what is tabular data is debatable. Regardless the table div comparison above is not accurate. Specifically, it would take more than one div to create a row cell structure… so when you need to display data in that structure it’s actually exactly the same amount of html whether you use a table or nested divs. E.g. bootstrap requires a container, row, and something equal to a td but I can’t recall which. So, if that’s the structure it uses the same amount of code. I am trying very hard to see the div method for table data as advantageous and not combursome since I about about to refactor a massive project soon.
Exactly!
And now it’s 10 years later, 2019, WYSIWYG editors are no longer WYSIWYG but a complicated and incomprehensible hodgepodge, only one of which automatically adjusts for the many mobile device and display sizes, loading time is irrelevant and I’m about to do a site with tables. I’ve been coding on and off since the mid 90’s and have been hearing about tables are only for tabular data blah blah blah for years. Maybe it’s because I learned with tables when I was getting started but Divs are complicated and they absolutely do require more code most of the time when you consider practically each object needs to be assigned an ID and go along with a class . And if you want to use a wysiwyg editor, they just don’t work properly anymore in 2019. There is no drag and drop anymore. You either learn code or you use a 1990’s style basic editor where you can assemble a site in minutes with tables that will adjust to a any modern display or device. Tables have proven themselves and I’m going old school. I don’t care what anybody says.
Luckily, modern sites have actually become pretty basic. They don’t need a lot of fancy features or tons of content. Tables will get you on the air with display compatibility quickly and with confidence.
WYSIWYG editors seem a lot better to me today than they were 10 years ago. They’re much easier to use now.
To each their own in regards to tables. You’re welcome to use them to layout sites if you want. No one is going to stop you. However, the industry moved on from them a long time ago. It’s now moving on from the CSS methods that replaced tables and using CSS that’s being written specifically to lay out sites. I’d rather use the more forward thinking approach, but again to each their own.