As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
It seems to be the general opinion that tables should not be used for layout in HTML.
Why?
I have never (or rarely to be honest) seen good arguments for this. The usual answers are:
It's good to separate content from layoutBut this is a fallacious argument; Cliche Thinking. I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and CSS.By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.
Readability of the codeI think it's the other way around. Most people understand HTML, few understand CSS.
It's better for SEO not to use tablesWhy? Can anybody show some evidence that it is? Or a statement from Google that tables are discouraged from an SEO perspective?
Tables are slower.An extra tbody element has to be inserted. This is peanuts for modern web browsers. Show me some benchmarks where the use of a table significantly slows down a page.
A layout overhaul is easier without tables, see css Zen Garden.Most web sites that need an upgrade need new content (HTML) as well. Scenarios where a new version of a web site only needs a new CSS file are not very likely. Zen Garden is a nice web site, but a bit theoretical. Not to mention its misuse of CSS.
I am really interested in good arguments to use divs + CSS instead of tables.
I'm going to go through your arguments one after another and try to show the errors in them.
It's good to separate content from layout
But this is a fallacious argument; Cliché Thinking.
It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.
So what? Does my boss care? Do my users care?
Depends. Is your boss pointy-haired? Then he might not care. If she's competent, then she will care, because the users will.
Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.
The majority of professional web developers seem to oppose you[citation needed]. That tables are in fact less maintainable should be obvious. Using tables for layout means that changing the corporate layout will in fact mean changing every single page. This can be very expensive. On the other hand, judicious use of semantically meaningful HTML combined with CSS might confine such changes to the CSS and the pictures used.
By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.
Deeply nested <div>s are an anti-pattern just as table layouts. Good web designers don't need many of them. On the other hand, even such deep-nested divs don't have many of the problems of table layouts. In fact, they can even contribute to a semantic structure by logically dividing the content in parts.
Readability of the code
I think it's the other way around. Most people understand html, little understand css. It's simpler.
“Most people” don't matter. Professionals matter. For professionals, table layouts create many more problems than HTML + CSS. This is like saying I shouldn't use GVim or Emacs because Notepad is simpler for most people. Or that I shouldn't use LaTeX because MS Word is simpler for most people.
It's better for SEO not to use tables
I don't know if this is true and wouldn't use this as an argument but it would be logical. Search engines search for relevant data. While tabular data could of course be relevant, it's rarely what users search for. Users search for terms used in the page title or similarly prominent positions. It would therefore be logical to exclude tabular content from filtering and thus cutting the processing time (and costs!) by a large factor.
Tables are slower.
An extra tbody element has to be inserted. This is peanuts for modern web browsers.
The extra element has got nothing to do with tables being slower. On the other hand, the layout algorithm for tables is much harder, the browser often has to wait for the whole table to load before it can begin to layout the content. Additionally, caching of the layout won't work (CSS can easily be cached). All this has been mentioned before.
Show me some benchmarks where the use of a table significantly slows down a page.
Unfortunately, I don't have any benchmark data. I would be interested in it myself because it's right that this argument lacks a certain scientific rigour.
Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.
Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.
Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.
Here's my programmer's answer from a simliar thread
Semantics 101
First take a look at this code and think about what's wrong here...
class car {
int wheels = 4;
string engine;
}
car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;
The problem, of course, is that a bike is not a car. The car class is an inappropriate class for the bike instance. The code is error-free, but is semantically incorrect. It reflects poorly on the programmer.
Semantics 102
Now apply this to document markup. If your document needs to present tabular data, then the appropriate tag would be <table>. If you place navigation into a table however, then you're misusing the intended purpose of the <table> element. In the second case, you're not presenting tabular data -- you're (mis)using the <table> element to achieve a presentational goal.
Conclusion
Will visitors notice? No. Does your boss care? Maybe. Do we sometimes cut corners as programmers? Sure. But should we? No. Who benefits if you use semantic markup? You -- and your professional reputation. Now go and do the right thing.
Obvious answer: See CSS Zen Garden. If you tell me that you can easily do the same with a table-based layout (remember - the HTML isn't changing) then by all means use tables for layout.
Two other important things are accessibility and SEO.
Both care about in what order information is presented. You cannot easily present your navigation at the top of the page if your table-based layout puts it in the 3rd cell of the 2nd row of the 2nd nested table on the page.
So your answers are maintainability, accessibility and SEO.
Don't be lazy. Do things the right and proper way even if they are a bit harder to learn.
See this duplicate question.
One item you're forgetting there is accessibility. Table-based layouts don't translate as well if you need to use a screen reader, for example. And if you do work for the government, supporting accessible browsers like screen readers may be required.
I also think you underestimate the impact of some of the things you mentioned in the question. For example, if you are both the designer and the programmer, you may not have a full appreciation of how well it separates presentation from content. But once you get into a shop where they are two distinct roles the advantages start to become clearer.
If you know what you're doing and have good tools, CSS really does have significant advantages over tables for layout. And while each item by itself may not justify abandoning tables, taken together it's generally worth it.
Unfortunately, CSS Zen Garden can no longer be used as an example of good HTML/CSS design. Virtually all of their recent designs use graphics for section heading. These graphic files are specified in the CSS.
Hence, a website whose purpose is to show the advantage of keeping design out of content, now regularly commits the UNSPEAKABLE SIN of putting content into design. (If the section heading in the HTML file were to change, the section heading displayed would not).
Which only goes to show that even those advocate the strict DIV & CSS religion, can't follow their own rules. You may use that as a guideline in how closely you follow them.
This isn't the definitive argument, by any means, but with CSS you can take the same markup and change the layout depending on medium, which is a nice advantage. For a print page you can quietly suppress navigation without having to create a printer-friendly page, for example.
One table for layout wouldn't be that bad. But you can't get the layout you need with just one table most of the time. Pretty soon you have 2 or three nested tables. This becomes very cumbersome.
It IS a LOT harder to read. That's not up to opinion. There's just more nested tags with no identifying marks on them.
Separating content from presentation is a good thing because it allows you to focus on what you're doing. Mixing the two leads to bloated pages that are hard to read.
CSS for styles allows your browser to cache the files and subsequent requests are much faster. This is HUGE.
Tables lock you into a design. Sure, not everyone needs the flexibility of CSS Zen Garden, but I've never worked on a site where I didn't need to change the design a little bit here and there. It's much easier with CSS.
Tables are hard to style. You don't have very much flexibility with them (i.e. you still need to add HTML attributes to fully control a table's styles)
I haven't used tables for non-tabular data in probably 4 years. I haven't looked back.
I'd really like to suggest reading CSS Mastery by Andy Budd. It's fantastic.
Image at ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg
It's good to separate content from layout
But this is a fallacious argument; Cliche Thinking
It's a fallacious argument because HTML tables are layout! The content is the data in the table, the presentation is the table itself. This is why separating CSS from HTML can be very difficult at times. You're not separating content from presentation, you're separating presentation from presentation! A pile of nested divs is no different than a table - it's just a different set of tags.
The other problem with separating the HTML from the CSS is that they need intimate knowledge of one another - you really can't separate them fully. The tag layout in the HTML is tightly coupled with the CSS file no matter what you do.
I think tables vs divs comes down to the needs of your application.
In the application we develop at work, we needed a page layout where the pieces would dynamically size themselves to their content. I spent days trying to get this to work cross-browser with CSS and DIVs and it was a complete nightmare. We switched to tables and it all just worked.
However, we have a very closed audience for our product (we sell a piece of hardware with a web interface) and accessibility issues are not a concern for us. I don't know why screen readers can't deal with tables well, but I guess if that's the way it is then developers have to handle it.
CSS/DIV - it's just jobs for the design boys, isn't it. The hundreds of hours I've spent debugging DIV/CSS issues, searching the Internet to get some part of markup working with an obscure browser - it drives me mad. You make one little change and the whole layout goes horrendously wrong - where on eath is the logic in that. Spending hours moving something 3 pixels this way then something else 2 pixels the other to get them all to line up. This just seems plain wrong to me somehow. Just because you're a purist and something is "not the right thing to do" doesn't mean you should make use of it to the nth degree and under all circumstances, especially if it makes your life 1000 times easier.
So I've finally decided, purely on commercial grounds, although I keep use to minimum, if I anticipate 20 hours work to get a DIV placed correctly, I'll stick in a table. It's wrong, it upsets the purists, but in most cases it costs less time and is cheaper to manage. I can then concentrate on getting the application working as the customer wants, rather than pleasing the purists. They do pay the bills after all and my argument to a manager enforcing the use of CSS/DIV - I would merely point out the customers pay his salary as well!
The only reason all these CSS/DIV arguments occur is because of the shortcoming of CSS in the first place and because the browsers aren't compatible with each other and if they were, half the web designers in the world would be out of a job.
When you design a windows form you don't try moving controls around after you have laid them out so I kind of think it's strange to me why you would you want to do this with a web form. I simply can't understand this logic. Get the layout right to start with and what's the problem. I think it's because designers like to flirt with creativity, whilst application developers are more concerned with actually getting the application working, creating business objects, implementing business rules, working out how bits of customer data relates to each other, ensuring the thing meets the customers requirements - you know - like the real world stuff.
Don't get me wrong, both arguments are valid, but please don't critise developers for choosing an easier, more logical approach to designing forms. We often have more important things to worry about than the correct semantics of using a table over a div.
Case in point - based on this discussion I converted a few existing tds and trs to divs. 45 minutes messing about with it trying to get everything to line up next to each other and I gave up. TDs back in 10 seconds later - works - straight away - on all browsers, nothing more to do. Please try to make me understand - what possible justification do you have for wanting me to do it any other way!
Layout should be easy. The fact that there are articles written on how to achieve a dynamic three column layout with header and footer in CSS shows that it is a poor layout system. Of course you can get it to work, but there are literally hundreds of articles online about how to do it. There are pretty much no such articles for a similar layout with tables because it's patently obvious. No matter what you say against tables and in favor of CSS, this one fact undoes it all: a basic three column layout in CSS is often called "The Holy Grail".
If that doesn't make you say "WTF" then you really need to put down the kool-aid now.
I love CSS. It offers amazing styling options and some cool positioning tools, but as a layout engine it is deficient. There needs to be some type of dynamic grid positioning system. A straightforward way to align boxes on multiple axis without knowing their sizes first. I don't give a damn if you call it <table> or <gridlayout> or whatever, but this is a basic layout feature that is missing from CSS.
The larger problem is that by not admitting there are missing features, the CSS zealots have been holding CSS back from all it could be. I'd be perfectly happy to stop using tables if CSS provided decent multi-axis grid positioning like basically every other layout engine in the world. (You do realize this problem has already been solved many times in many languages by everyone except the W3C, right? And nobody else denied that such a feature was useful.)
Sigh. Enough venting. Go ahead and stick your head back in the sand.
According to 508 compliance (for screen readers for visually impared), tables should only be used to hold data and not for layout as it causes the screen readers to freak out. Or so I've been told.
If you assign names to each of the divs, you can skin them all together using CSS as well. They're just a bit more of a pain to get to sit the way you need them to.
Here's a section of html from a recent project:
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<div id="header">
<h1><!-- Page title --></h1>
<ol id="navigation">
<!-- Navigation items -->
</ol>
<div class="clearfix"></div>
</div>
<div id="sidebar">
<!-- Sidebar content -->
</div>
<!-- Page content -->
<p id="footer"><!-- Footer content --></p>
</body>
</html>
And here's that same code as a table based layout.
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<title>{DYNAMIC(TITLE)}</title>
<meta http-equiv="content-type" content="text/html;charset=utf-8" />
<meta http-equiv="Content-Style-Type" content="text/css" />
<link rel="stylesheet" type="text/css" href="./styles/base.css" />
</head>
<body>
<table cellspacing="0">
<tr>
<td><!-- Page Title --></td>
<td>
<table>
<tr>
<td>Navitem</td>
<td>Navitem</td>
</tr>
</table>
</td>
</tr>
</table>
<table>
<tr>
<td><!-- Page content --></td>
<td><!-- Sidebar content --></td>
</tr>
<tr>
<td colspan="2">Footer</td>
</tr>
</table>
</body>
</html>
The only cleanliness I see in that table based layout is the fact that I'm overzealous with my indentation. I'm sure that the content section would have a further two embedded tables.
Another thing to think about: filesizes. I've found that table-based layouts are twice the size of their CSS counterparts usually. On our hig-speed broadband that isn't a huge issue but it is on those with dial up modems.
I'd like to add that div-based layouts are easer to mantain, evolve, and refactor. Just some changes in the CSS to reorder elements and it is done. From my experience, redesign a layout that uses tables is a nightmare (more if there are nested tables).
Your code also has a meaning from a semantic point of view.
No arguments in DIVs favour from me.
I'd say : If the shoe fits, wear it.
It's worth noting that it's difficult if not impossible to find a good DIV+CSS method of rendering contents in two or three columns, that is consistent on all browsers, and still looks just the way I intended.
This tips the balance a bit towards tables in most of my layouts, and altough I feel guilty of using them (dunny why, people just say it's bad so I try to listen to them), in the end , the pragmatic view is it's just easier and faster for me to use TABLEs. I'm not being payed by the hour, so tables are cheaper for me.
CSS layouts are generally much better for accessibility, provided the content comes in a natural order and makes sense without a stylesheet. And it's not just screen readers that struggle with table-based layouts: they also make it much harder for mobile browsers to render a page properly.
Also, with a div-based layout you can very easily do cool things with a print stylesheet such as excluding headers, footers and navigation from printed pages - I think it would be impossible, or at least much more difficult, to do that with a table-based layout.
If you're doubting that separation of content from layout is easier with divs than with tables, take a look at the div-based HTML at CSS Zen Garden, see how changing the stylesheets can drastically change the layout, and think about whether you could achieve the same variety of layouts if the HTML was table based... If you're doing a table-based layout, you're unlikely to be using CSS to control all the spacing and padding in the cells (if you were, you'd almost certainly find it easier to use floating divs etc. in the first place). Without using CSS to control all that, and because of the fact that tables specify the left-to-right and top-to bottom order of things in the HTML, tables tend to mean that your layout becomes very much fixed in the HTML.
Realistically I think it's very hard to completely change the layout of a div-and-CSS-based design without changing the divs a bit. However, with a div-and-CSS-based layout it's much easier to tweak things like the spacing between various blocks, and their relative sizes.
The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.
I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.
The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?
I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?
Google and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.
Having had to work with a website that involved 6 layers of nested tables generated by some application, and having had it generate invalid HTML, it was in fact a 3 hour job to rectify it breaking for a minor change.
This is of course the edge case, but table based design is unmaintainable. If you use css, you separate the style out so when fixing the HTML you have less to worry about breaking.
Also, try this with JavaScript. Move a single table cell from one place to another place in another table. Rather complicated to perform where div/span would just work copy-paste-wise.
"Does my boss care"
If I were your boss. You would care. ;) If you value your life.
Layout flexibility
Imagine you're making a page with a large number of thumbnails.
DIVs:
If you put each thumbnail in a DIV, floated left, maybe 10 of them fit on a row. Make the window narrower, and BAM - it's 6 on a row, or 2, or however many fit.
TABLE:
You have to explicitly say how many cells are in a row. If the window is too narrow, the user has to scroll horizontally.
Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE:
Paste the new cells into the third row. Oops! Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row... (etc)
(Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue.)
I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.
Also, don't forget, tables don't quite render well on mobile browsers. Sure, the iPhone has a kick-ass browser but everyone doesn't have an iPhone. Table rendering can be peanuts for modern browsers, but it's a bunch of watermelons for mobile browsers.
I have personally found that many people use too many <div> tags, but in moderation, it can be extremely clean and easy to read. You mention that folks have a harder time reading CSS than tables; in terms of 'code' that maybe true; but in terms of reading content (view > source) it is a heck of a lot easier to understand the structure with stylesheets than with tables.
Looks like you are just used to tables and that's it.
Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/
And no, layout does not usally require a lot of nested divs.
With no tables for layout and proper semantics HTML is much cleaner, hence easier to read.
Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.
SEO benefits come from the ability to have most important content higher up the page and
having better content-to-markup ratio.
http://www.hotdesign.com/seybold/
508 Compliance - the ability for a screenreader to make sense of your markup.
Waiting for render - tables don't render in the browser until it gets to the end of the </table> element.
The whole idea around semantic markup is the separation of markup and presentation, which includes layout.
Div's aren't replacing tables, they have their own use in separating content into blocks of related content (, ). When you don't have the skills and are relying on tables, you'll often have to separate your content in to cells in order to get the desired layout, but you wont need to touch the markup to achieve presentation when using semantic markup. This is really important when the markup is being generated rather than static pages.
Developers need to stop providing markup that implies layout so that those of us who do have the skills to present content can get on with our jobs, and developers don't have to come back to their code to make changes when presentation needs change.
This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings - technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.
Tools that use table layouts can become extraordinarily heavy due to the amount of code required to create the layout. SAP's Netweaver Portal by default uses TABLE to layout their pages.
The production SAP portal at my current gig has a home page whose HTML weighs over 60K and goes seven tables deep, three times within the page. Add in the Javascript, the misuse of 16 iframes with similar table issues inside of them, overly heavy CSS etc, and the page weighs over 5MB.
Taking the time to lower the page weight so you can use your bandwidth to do engaging activities with users is worth the effort.
It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.
The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.
The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?
If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques -- divs, tables, JavaScript, includes, functions, objects, continuations, whatever -- to structure the application so that the changes fit in a simple and comfortable manner.
Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them -- but hey, welcome to the world of computers).
Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.
It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.
Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.
CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font-tags are better than specifying typography in CSS, since CSS gives you the same power than font-tags, but in a much cleaner way.
The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer - in other browsers this is easliy achieved by using display:table-cell).
So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.
The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.
I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:
.1. CSS & SEO:
a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.
b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google
c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout
.2. Generated content:
A table is considerably easier to generate programmically than the equivalent CSS layout.
foreach ($comment as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}
Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).
Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.
This is one reason why some very well designed websites (SO for instance) still use table layouts.
Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.
.3. Quick conversion testing
When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier
.4. Different solutions for different problems
Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.
However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)
There are a lot of downsides to tables, including maintenance, lack of flexibility... but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.
Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS
I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"
As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?
I am a newby to design and looking now into the use of background instead of foreground images, which is a common practice.
I look at the techniques used, and see that:
you usually need to explicitly state the dimensions of the image (and set the foreground element to these dimensions)
you need to make the foreground element to somehow disappear with css tricks.
All this looks really hackish. So, I wonder, why on earth do all this instead of just using the native element? I am sure there is a good answer
(I did go through this When to use IMG vs. CSS background-image? , and could not figure out a clear answer)
One thing to consider as a benefit to using CSS for images is that you can load all your design images (images for UI elements, etc) with one http request rather than an http request for each individual image using a sprite. One large image that contains a grid of all your images.
As its been stated before, content images should use the img tag which also helps for people using various accessibility options when visiting your site/app. For example, if they are using a screenreader, the screenreader knows its an image and can read the img alt name or title, but if its just a div with a background image they get nothing.
The main difference is that in the img tag the image is hardcoded.
With CSS you can create different designs, switch between them, redesign the page, without altering the source code. To see the power of CSS, check http://www.csszengarden.com/, all the pages use the same HTML source, but with different CSS layout.
As #Shmiddty noted, if img is for embedded images (actual content, for example a gallery, or a picture for an article), and CSS is for design.
Also, the question you referred to, has nice list of all the use-cases: When to use CSS background-image.
The goal is to separate content from presentation. HTML should contain just content, and all presentation should be moved to the CSS. Once you achieve that, you gain a few useful side effects:
The CSS (presentational code) is cached by the user's browser, and each HTML file requested is smaller. This also has some SEO benefits (decreased code fluff).
Screen readers have to muddle through less when interpreting your page for visually impaired users. Making sure your HTML contains just content means visually impaired users reach what they're looking for much quicker.
CSS makes it possible to display the same content in different visual configurations, which is the cornerstone of the responsive web design movement. Properly delineating your content and presentation means being able to use the same HTML files across multiple platforms (desktop, tablet, smartphone).
However, there are times when images are content on a specific page. In those cases, you want to use an IMG tag, and moving the image to the CSS is actually a wrong move. A great discussion of when and where to use text to image replacement is at When to use IMG vs. CSS background-image? Basically, my personal litmus test is something like: Is this image going to be used multiple times on the site? If it is, it's probably part of the design. Once-off images are generally content.
If you're looking to move your design images to the CSS, congratulations :-p You've adopted a healthy amount of work, but started doing something worthwhile to the long-term health of your website as part of the web ecosystem. I would highly recommend looking into using the SASS/Compass system to manage your design images as sprites (see A List Apart:CSS Sprites and Spriting with Compass).
One of the main points of image replacement is to use your site title in a h1 tag for good SEO, and then hiding the text and replacing it with a custom logo.
This also makes your site more accessible. Say for example, your user has CSS disabled for whatever reason (screenreaders, maybe). They would still see the textual representation of your site title, whereas normal users would see the custom graphic.
I haven't done any real web design in a few years, and I'm now tasked with creating a set of web pages that will need relatively complex (and exact) layouts. I've started exploring CSS, and while I'm starting to get an idea of how to use it, it doesn't really seem like the appropriate tool for the kind of layout I need.
The layout I need has a top, middle, and bottom section, and each of those sections is broken down into different areas. I need something that is kinda like:
35%, 35% (right justified), 15%, 15%
70%, 15%, 15%
70%, 15%, 15%
Percents are of browser width, and where the percentage of the column end is the same as the row above/below, the columns edges need to meet. Further, rows must be below each other, regardless of what content I put in them.
CSS seemed like it would do what I want, but then when I started trying for the complexity I needed, I couldn't get columns to match up, or rows flowed into other rows, etc.
What I really want is something like frames, where I can position elements exactly where I want them. Does that exist, or do I just fight with CSS?
Thanks,
Sean.
You need to learn CSS, not fight it. CSS has been used to create much more complex layouts than what you have described. And it is the only way you should be styling your web pages and implementing a layout design.
CSS gives you much more control over the presentation of a webpage and positioning of elements than frames can (frames only give you frames to put load multiple pages in; you still need to style those pages separately).
This is a rather broad question, so I'll just say this:
Use HTML to semantically organize/structure your content.
Use CSS for your presentation.
In other words, don't use any of the following tags or similar tags:
<b> (use <strong> instead)
<i> (use <em> instead)
<font>
<u>
Remember to use structuring tags where appropriate like:
<h1> up to <h6>
<p>
<blockquote>
<pre>
And use semantically correct tags. So if you have a definition list, use <dl>, <dt> and <dd>. If you have a form, use <label for="{input id}">, e.g.:
<label for="first-name">First Name:</label>
<input name="first_name" id="first-name" />
<!-- when the user clicks on the label, the input will receive focus -->
Don't use tables for layouts. Use them only for tabular data. And when you do, make sure you use proper semantic markup <thead>, <th>, <tbody>, etc.
Put title attributes in your links and alt attributes in your images for accessibility and usability.
And use stylesheets (preferably external ones for DRY) instead of inline styles.
Lastly, as Jan_V mentioned, w3schools.com is a great resource for CSS, JavaScript, HTML, and most web standards. There is a lot for you to learn, but luckily there's a ton of tutorials, references, and other resources on the web to help you along. Learn how to properly use CSS/HTML, and you will produce higher quality webpages as well as save time in maintenance.
If you're struggling with the layout you have in mind, start with something simpler and work your way up. E.g. try an evenly drawn 2 column, 2 row layout first. Once you get that working, start changing the proportions and adding more columns/rows.
CSS can do pretty much anything you want, it is the defacto tool for positioning and styling elements on your web pages. I think you should look into position: absolute and float capabilities based on your description. The difficulty with it lies in getting consistent behavior/interpretations across browsers. Using a css-reset like YUI's is highly recommended to help with this. YUI also has javascript utilities that help normalize some CSS behavior (e.g. float and opacity) across browsers. YUI is by no means the only way of accomplishing these goals.
You could try using tables for the layout, but I would suggest using CSS and DIV elements.
If you are going to use frames or tables you'll get in trouble later (probably). Also, CSS isn't that hard, just spend a bit time on learning it and maybe W3Schools, which have nice tutorials.
Remember using Tables as apposed to CSS will cause accessibility problems. This means that people with using accessibility to browse your site will have problems using screen readers.
I agree with some of the previous answers. Spend time getting to know CSS. When it is written correctly it means that your styles will be reuseable and easy to implement and change once you have done them. Trying to change styles that have been individualy coded on a number of pages will cause you headaches.
If your website is going to be complex then try and make sure you are making it as simple to maintain as possible and CSS will definately help you there.
I'm working on a web app that currently has a table-based layout. Ideally I'd like to go to pure css, or failing that, a hybrid tables-and-css layout* .
I've banged my head against the wall trying to understand css layouts and positioning. The main problem I'm encountering is that, depending on the state of the app, I have different things appearing in a 'section' of the layout -- what might be contained in a div or table. For instance, I might have some text and links, and then after user interaction, there might be a form, a table, some images, different text, etc. Anytime I find a css solution, it is for a fixed-element layout, or works in a specific case, etc. They're not robust solutions, in other words.
From this In Search of the One True Layout, the author about "Vertical placement of elements across grids/columns": "Designers face the choice of relying on elements being a particular height, resorting to tables or simply not bothering." Is this true? In my app, I can't rely on elements being a particular height.
Do I fall back on tables when I have elements of various hieghts ( which is quite a bit of the site, actually). I noticed that quite a bit of sites done by well-respected people and organizations use tables for layout in certain places, and not just for tabular data! This site included.
The chances are that there are CSS techniques to achieve what you want, but they may not be obvious if using CSS for complex layouts is new to you.
In your case, to 'get it done', I would recommend a hybrid type layout, and not feel bad about using a table to layout the pieces of the application that require those particular behaviours.
If it is particularly complex and difficult than a table might be the best and simplest approach even for the CSS expert.
Dynamic heights are only a problem if you need to implement a special effect of soem sort or a background image and oftent there are ways around that. It really depends on the Visual Design and what needs to be done to make each "block" flexible to use. Sometimes things arent possible but most of the time they are - they jsut tend to add complexity to the markup. But even that added complexity is easier for me to understand than nested tables :-)
My advice if you want to get things done and spend a ridiculous amount of time on css layout, browser compatibility, CSS reset, fonts:
write simple, valid, semantic HTML
use a simple CSS framework (like blueprint). You will rely on a simple grid system for positioning and layout.
add CSS classes to your HTML
add your custom CSS for colors, backgrounds...
Please reconsider using a table layout 'to get it done'; you will be disappointed, especially if you want to add some JS magic later.
I use CSS layouts for my web apps. But, my apps don't have wildly varying information, so I can set the content area and not have to worry about the layout looking "off" because a column is way out of balance with the rest of the content.
If you're having trouble with CSS layout and positioning, I'd suggest tables first, learn more about CSS/HTML positioning, and then convert your layout LATER. I'm sure that it's made for a frustrating experience learning CSS on a "real" project.
In the meantime, get some really good sources for CSS: books by Andy Budd, Simon Collison, Eric Meyer, et. al. Also, go to their blogs and dig into the archives. A really good book for CSS layout, positioning and general use is Beginning CSS Web Development by Simon Collison from APress. All the ins and outs with great working examples.