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 layout
But 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 code
I think it's the other way around. Most people understand HTML, few understand CSS.
It's better for SEO not to use tables
Why? 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've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
As per my knowledge on tables, if too many tables are nested, there is a great overhead to browser in rendering the page.
1 - The browser has wait to render the final view wait until the entire table gets loaded.
2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!
How to optimize tables ? If you're using tables, I would suggest, always define width for the cells. This does not guarantees that browser will blindly take this widths only, but would be of great help to browser in deciding the initial widths.
But, at the end, div are great way as CSS can be cached by the browser; while table aren't cached !
DOM Manipulation is difficult in a table-based layout.
With semantic divs:
$('#myawesomediv').click(function(){
// Do awesome stuff
});
With tables:
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
Now, granted, the second example is kind of stupid, and you can always apply IDs or classes to a table or td element, but that would be adding semantic value, which is what table proponents so vehemently oppose.
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.
</table> element.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?
By still using table for layouts, we are missing on the innovation on the div side.
Many have come up with solutions that make creating layout for divs easier. The most popular being the grid architecture. There are dynamic layout generators based on this architecture. Check out: 1) 960.gs and (http://grids.heroku.com/) 2) blueprint and so many of late.
I have not seen much of innovation in terms of architecture and tools with the tables layout.
I would say, all the theories aside, practically layout with CSS and divs are faster. Rather innovation in this direction made it easier than anything.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
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.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
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.
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
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.
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
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.
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?
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.
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.
Flex has a tag for laying things out in vertical columns. I don't think they got the whole layout/content thing right either to be honest, but at least they've resolved that issue.
Like many of the people frustrated with CSS I've also looked far and wide for an easy answer, was duped into feeling elated when I thought I had found it, and then had my hopes dashed to pieces when I opened the page in Chrome. I'm definitely not skilled enough to say it's not possible, but I haven't seen anyone offer up sample code for peer review proving unequivocally that it can be done reliably.
So can someone from the CSS side of this island recommend a mindset/methodology for laying out vertical columns? I've tried absolute positioning in second and third rows, but i end up with stuff overlapping everywhere and float has similar issues if the page is shrunk down.
If there was an answer to this I'd be ecstatic to -do the right thing- Just tell me something like, "Hey have you tried **flow:vertical|horizontal" and I'm totally out of your hair.
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
I'm sorry for my English but here's another reason :
I worked in some governmental organization and the number one reason to not use TABLE, is for disabled peoples. They use machines to "translate" web pages.
The problem is this "translation machine" can't read the website if it's done by TABLE. Why ? Because TABLE are for DATAS.
in fact, if you use TABLES, for each CELLS you have to specify some informations to let disabled people to know where they are in the TABLE. Imagine you have a big table and have to zoom to see only 1 cell in the screen : you have to know in which line/col you are.
So, DIV are used, and the disabled can simply read text, and don't get some weird informations about lines/cols when they don't have to be there.
I also prefer TABLE to make quick and easy templates, but I'm now used to CSS... it's powerful, but you really have to know what you are doing... :)
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
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'm sorry for my English but here's another reason :
I worked in some governmental organization and the number one reason to not use TABLE, is for disabled peoples. They use machines to "translate" web pages.
The problem is this "translation machine" can't read the website if it's done by TABLE. Why ? Because TABLE are for DATAS.
in fact, if you use TABLES, for each CELLS you have to specify some informations to let disabled people to know where they are in the TABLE. Imagine you have a big table and have to zoom to see only 1 cell in the screen : you have to know in which line/col you are.
So, DIV are used, and the disabled can simply read text, and don't get some weird informations about lines/cols when they don't have to be there.
I also prefer TABLE to make quick and easy templates, but I'm now used to CSS... it's powerful, but you really have to know what you are doing... :)
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
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.
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
One example: you want to center the main content area of a page, but in order to contain the floats inside it, it needs to be floated. There is no "float: center" in CSS.
That is not the only way to "contain the floats" inside a centred element. So, not a good argument at all!
In a way, it's a false premise, the "divs vs tables" thing.
Quick-and-dirty division of a page into three columns? Tables are easier, to be honest. But no professional uses them any more for layout, because they lock the positioning of page elements into the page.
The real argument is "positioning done by CSS (hopefully in a remote file)" as opposed to "positioning done by HTML in the page". Surely everyone can see the benefits of the former as opposed to the latter?
Consider this:
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
which represents two rows of a table with 6 cells. Someone who can see the 2-D table layout will see a caption under each picture. But using speech synthesis, or a PDA, and for a search engine spider, that's
picture picture picture caption caption caption
and the relationship, which is obvious with the table in place, disappears.
Are DIVs and CSS better for the task of simply laying out rectangles on an HTML page to achieve a given design in the shortest possible time? No, they're probably not. But I'm not in the business of quickly laying out rectangles to achieve a given design. I'm thinking of a much bigger picture.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
By still using table for layouts, we are missing on the innovation on the div side.
Many have come up with solutions that make creating layout for divs easier. The most popular being the grid architecture. There are dynamic layout generators based on this architecture. Check out: 1) 960.gs and (http://grids.heroku.com/) 2) blueprint and so many of late.
I have not seen much of innovation in terms of architecture and tools with the tables layout.
I would say, all the theories aside, practically layout with CSS and divs are faster. Rather innovation in this direction made it easier than anything.
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.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
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.
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.
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.)
When I design my layout using CSS, I generally give every major section its own root (body level) div, and use relative/absolute positioning to get it into its proper place. This is a bit more flexible than tables, as I'm not limited to an arrangement that I can represent using rows and columns.
Furthermore, if I decide that I want to rearrange the layout (say I want the navigation bar to be on the right now) I can simply go and alter the position for the elements in one place (the CSS file) and the HTML doesn't have to change. If I were doing that with tables, I would have to go in and find the information and do a lot of attribute modding and copying and pasting to get the same effect.
In fact, using CSS, I can even have my users select how they want their layout to work. So long as the general size of the content areas doesn't change, I'm perfectly OK with using a bit of PHP scripting to output my CSS based on user preferences, and allowing them to rearrange the site to their own liking. Once again, possible with tables, but much much harder to maintain.
Finally, CSS allows one MAJOR benefit that tables will never provide: the ability to reformat content based on the display device. CSS allows me to use a completely different style set (including position, formatting, etc) for a printer than the one I use for the monitor. This can be extended to other media as well, an excellent example is Opera Show, which allows a cleverly designed (and very standard) CSS enhanced page to be viewed as a slide show.
So in the end, flexibility and management are the real winners. Generally, CSS allows you to do more with the layout. There's nothing technically nonstandard about a table based layout, but why would you want to limit yourself?
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
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.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
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 try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
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.
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.
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.
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.
I'm sorry for my English but here's another reason :
I worked in some governmental organization and the number one reason to not use TABLE, is for disabled peoples. They use machines to "translate" web pages.
The problem is this "translation machine" can't read the website if it's done by TABLE. Why ? Because TABLE are for DATAS.
in fact, if you use TABLES, for each CELLS you have to specify some informations to let disabled people to know where they are in the TABLE. Imagine you have a big table and have to zoom to see only 1 cell in the screen : you have to know in which line/col you are.
So, DIV are used, and the disabled can simply read text, and don't get some weird informations about lines/cols when they don't have to be there.
I also prefer TABLE to make quick and easy templates, but I'm now used to CSS... it's powerful, but you really have to know what you are doing... :)
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
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.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
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.
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.
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.
When I design my layout using CSS, I generally give every major section its own root (body level) div, and use relative/absolute positioning to get it into its proper place. This is a bit more flexible than tables, as I'm not limited to an arrangement that I can represent using rows and columns.
Furthermore, if I decide that I want to rearrange the layout (say I want the navigation bar to be on the right now) I can simply go and alter the position for the elements in one place (the CSS file) and the HTML doesn't have to change. If I were doing that with tables, I would have to go in and find the information and do a lot of attribute modding and copying and pasting to get the same effect.
In fact, using CSS, I can even have my users select how they want their layout to work. So long as the general size of the content areas doesn't change, I'm perfectly OK with using a bit of PHP scripting to output my CSS based on user preferences, and allowing them to rearrange the site to their own liking. Once again, possible with tables, but much much harder to maintain.
Finally, CSS allows one MAJOR benefit that tables will never provide: the ability to reformat content based on the display device. CSS allows me to use a completely different style set (including position, formatting, etc) for a printer than the one I use for the monitor. This can be extended to other media as well, an excellent example is Opera Show, which allows a cleverly designed (and very standard) CSS enhanced page to be viewed as a slide show.
So in the end, flexibility and management are the real winners. Generally, CSS allows you to do more with the layout. There's nothing technically nonstandard about a table based layout, but why would you want to limit yourself?
I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money.
Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force.
I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism.
I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS.
Thankfully it now appears that a solution to these issues is now available - its called WPF.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
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.
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.
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.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
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.
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.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
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.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
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.
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?
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
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.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
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.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
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.
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.
I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money.
Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force.
I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism.
I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS.
Thankfully it now appears that a solution to these issues is now available - its called WPF.
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.
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.)
</table> element.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.)
WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
One example: you want to center the main content area of a page, but in order to contain the floats inside it, it needs to be floated. There is no "float: center" in CSS.
That is not the only way to "contain the floats" inside a centred element. So, not a good argument at all!
In a way, it's a false premise, the "divs vs tables" thing.
Quick-and-dirty division of a page into three columns? Tables are easier, to be honest. But no professional uses them any more for layout, because they lock the positioning of page elements into the page.
The real argument is "positioning done by CSS (hopefully in a remote file)" as opposed to "positioning done by HTML in the page". Surely everyone can see the benefits of the former as opposed to the latter?
Consider this:
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
which represents two rows of a table with 6 cells. Someone who can see the 2-D table layout will see a caption under each picture. But using speech synthesis, or a PDA, and for a search engine spider, that's
picture picture picture caption caption caption
and the relationship, which is obvious with the table in place, disappears.
Are DIVs and CSS better for the task of simply laying out rectangles on an HTML page to achieve a given design in the shortest possible time? No, they're probably not. But I'm not in the business of quickly laying out rectangles to achieve a given design. I'm thinking of a much bigger picture.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
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.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
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.
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.
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.
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.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
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.
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.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
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.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
</table> element.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.)
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 once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
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.
I researched the issue of screen readers and tables a few years ago and came up with information that contradicts what most developers believe:
http://www.webaim.org/techniques/tables/
"You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind. "
I'm sorry for my English but here's another reason :
I worked in some governmental organization and the number one reason to not use TABLE, is for disabled peoples. They use machines to "translate" web pages.
The problem is this "translation machine" can't read the website if it's done by TABLE. Why ? Because TABLE are for DATAS.
in fact, if you use TABLES, for each CELLS you have to specify some informations to let disabled people to know where they are in the TABLE. Imagine you have a big table and have to zoom to see only 1 cell in the screen : you have to know in which line/col you are.
So, DIV are used, and the disabled can simply read text, and don't get some weird informations about lines/cols when they don't have to be there.
I also prefer TABLE to make quick and easy templates, but I'm now used to CSS... it's powerful, but you really have to know what you are doing... :)
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
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.
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.
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.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
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.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
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.
Super short answer: designing maintainable websites is difficult with tables, and simple with the standard way to do it.
A website isn't a table, it's a collection of components that interact with each other. Describing it as a table doesn't make sense.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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?
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.
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.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.
As per my knowledge on tables, if too many tables are nested, there is a great overhead to browser in rendering the page.
1 - The browser has wait to render the final view wait until the entire table gets loaded.
2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!
How to optimize tables ? If you're using tables, I would suggest, always define width for the cells. This does not guarantees that browser will blindly take this widths only, but would be of great help to browser in deciding the initial widths.
But, at the end, div are great way as CSS can be cached by the browser; while table aren't cached !
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.
Flex has a tag for laying things out in vertical columns. I don't think they got the whole layout/content thing right either to be honest, but at least they've resolved that issue.
Like many of the people frustrated with CSS I've also looked far and wide for an easy answer, was duped into feeling elated when I thought I had found it, and then had my hopes dashed to pieces when I opened the page in Chrome. I'm definitely not skilled enough to say it's not possible, but I haven't seen anyone offer up sample code for peer review proving unequivocally that it can be done reliably.
So can someone from the CSS side of this island recommend a mindset/methodology for laying out vertical columns? I've tried absolute positioning in second and third rows, but i end up with stuff overlapping everywhere and float has similar issues if the page is shrunk down.
If there was an answer to this I'd be ecstatic to -do the right thing- Just tell me something like, "Hey have you tried **flow:vertical|horizontal" and I'm totally out of your hair.
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
I researched the issue of screen readers and tables a few years ago and came up with information that contradicts what most developers believe:
http://www.webaim.org/techniques/tables/
"You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind. "
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 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?
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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!
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.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
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.
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.
Super short answer: designing maintainable websites is difficult with tables, and simple with the standard way to do it.
A website isn't a table, it's a collection of components that interact with each other. Describing it as a table doesn't make sense.
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.
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.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
</table> element.I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
DOM Manipulation is difficult in a table-based layout.
With semantic divs:
$('#myawesomediv').click(function(){
// Do awesome stuff
});
With tables:
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
Now, granted, the second example is kind of stupid, and you can always apply IDs or classes to a table or td element, but that would be adding semantic value, which is what table proponents so vehemently oppose.
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.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
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.
</table> element.Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money.
Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force.
I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism.
I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS.
Thankfully it now appears that a solution to these issues is now available - its called WPF.
Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.
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.
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.
DOM Manipulation is difficult in a table-based layout.
With semantic divs:
$('#myawesomediv').click(function(){
// Do awesome stuff
});
With tables:
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
Now, granted, the second example is kind of stupid, and you can always apply IDs or classes to a table or td element, but that would be adding semantic value, which is what table proponents so vehemently oppose.
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.
One example: you want to center the main content area of a page, but in order to contain the floats inside it, it needs to be floated. There is no "float: center" in CSS.
That is not the only way to "contain the floats" inside a centred element. So, not a good argument at all!
In a way, it's a false premise, the "divs vs tables" thing.
Quick-and-dirty division of a page into three columns? Tables are easier, to be honest. But no professional uses them any more for layout, because they lock the positioning of page elements into the page.
The real argument is "positioning done by CSS (hopefully in a remote file)" as opposed to "positioning done by HTML in the page". Surely everyone can see the benefits of the former as opposed to the latter?
Consider this:
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
which represents two rows of a table with 6 cells. Someone who can see the 2-D table layout will see a caption under each picture. But using speech synthesis, or a PDA, and for a search engine spider, that's
picture picture picture caption caption caption
and the relationship, which is obvious with the table in place, disappears.
Are DIVs and CSS better for the task of simply laying out rectangles on an HTML page to achieve a given design in the shortest possible time? No, they're probably not. But I'm not in the business of quickly laying out rectangles to achieve a given design. I'm thinking of a much bigger picture.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
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.
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.
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.
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
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.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.
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.
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!
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
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.
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.
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.
I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
By still using table for layouts, we are missing on the innovation on the div side.
Many have come up with solutions that make creating layout for divs easier. The most popular being the grid architecture. There are dynamic layout generators based on this architecture. Check out: 1) 960.gs and (http://grids.heroku.com/) 2) blueprint and so many of late.
I have not seen much of innovation in terms of architecture and tools with the tables layout.
I would say, all the theories aside, practically layout with CSS and divs are faster. Rather innovation in this direction made it easier than anything.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
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.
WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
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.
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.
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.
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.
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.
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.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
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.
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.
I've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.
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.
</table> element.I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
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.
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
Super short answer: designing maintainable websites is difficult with tables, and simple with the standard way to do it.
A website isn't a table, it's a collection of components that interact with each other. Describing it as a table doesn't make sense.
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.
I do believe this is an issue connected to a general problem. When HTML was born no one could foresee its widespread use. Another technology which almost collapsed under the weight of its own success. When HTML pages were written in vi on a green text terminal a TABLE was all that was needed to present data to the visitors of the page, and it mostly was data that made sense in a tabular form.
We all know how things evolved. TABLEs went out of fashion comparatively recently, but there are lots of reasons to prefer DIVs and CSS based layouts (accessibility not the last of them). Of course I can't write a CSS to save my life :-) and I think a graphical design expert should always be at hand.
That said... there are lots of data that should be presented in a table even in a modern web site.
By still using table for layouts, we are missing on the innovation on the div side.
Many have come up with solutions that make creating layout for divs easier. The most popular being the grid architecture. There are dynamic layout generators based on this architecture. Check out: 1) 960.gs and (http://grids.heroku.com/) 2) blueprint and so many of late.
I have not seen much of innovation in terms of architecture and tools with the tables layout.
I would say, all the theories aside, practically layout with CSS and divs are faster. Rather innovation in this direction made it easier than anything.
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.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
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.
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 researched the issue of screen readers and tables a few years ago and came up with information that contradicts what most developers believe:
http://www.webaim.org/techniques/tables/
"You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind. "
The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.
For simple layout issues why not bend the rule that says presentation must be completely separate? What about a new tag (or some extension to the div tag) that allows us to control presentation directly in HTML? After all, aren't we already leaking presentation into HTML? Look at h1, h2...h6. We all know these control presentation.
The ability to read code (and HTML is code) is very important. Gurus tend to overlook how important it is to make a programming environment as accessible to the masses as possible. It is very shortsighted to think that only professional programmers matter.
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
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.
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.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
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.
Flex has a tag for laying things out in vertical columns. I don't think they got the whole layout/content thing right either to be honest, but at least they've resolved that issue.
Like many of the people frustrated with CSS I've also looked far and wide for an easy answer, was duped into feeling elated when I thought I had found it, and then had my hopes dashed to pieces when I opened the page in Chrome. I'm definitely not skilled enough to say it's not possible, but I haven't seen anyone offer up sample code for peer review proving unequivocally that it can be done reliably.
So can someone from the CSS side of this island recommend a mindset/methodology for laying out vertical columns? I've tried absolute positioning in second and third rows, but i end up with stuff overlapping everywhere and float has similar issues if the page is shrunk down.
If there was an answer to this I'd be ecstatic to -do the right thing- Just tell me something like, "Hey have you tried **flow:vertical|horizontal" and I'm totally out of your hair.
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
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.
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.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
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.
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.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
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.
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.
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.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
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.
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.
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.
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.
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.
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.
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.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
As per my knowledge on tables, if too many tables are nested, there is a great overhead to browser in rendering the page.
1 - The browser has wait to render the final view wait until the entire table gets loaded.
2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!
How to optimize tables ? If you're using tables, I would suggest, always define width for the cells. This does not guarantees that browser will blindly take this widths only, but would be of great help to browser in deciding the initial widths.
But, at the end, div are great way as CSS can be cached by the browser; while table aren't cached !
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.
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.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
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.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
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.
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.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.
For simple layout issues why not bend the rule that says presentation must be completely separate? What about a new tag (or some extension to the div tag) that allows us to control presentation directly in HTML? After all, aren't we already leaking presentation into HTML? Look at h1, h2...h6. We all know these control presentation.
The ability to read code (and HTML is code) is very important. Gurus tend to overlook how important it is to make a programming environment as accessible to the masses as possible. It is very shortsighted to think that only professional programmers matter.
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.
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
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.
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.
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.)
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
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.
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.
Using DIV, you can easily switch things. For example, you could make this :
Menu | Content
Content | Menu
Menu
----
Content
It's easy to change it in CSS, not in HTML. You can also provide several styles (right handed, left handed, special for little screen).
In CSS, you can also hide the menu in a special stylesheet used for printing.
Another good thing, is that your content is always in the same order in the code (the menu first, the content after) even if visually it's presented otherwise.
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.
I researched the issue of screen readers and tables a few years ago and came up with information that contradicts what most developers believe:
http://www.webaim.org/techniques/tables/
"You will probably hear some accessibility advocates say that layout tables are a bad idea, and that CSS layout techniques ought to be used instead. There is truth in what they say, but, to be honest, using tables for layout is not the worst thing that you could do in terms of accessibility. People with all kinds of disabilities can easily access tables, as long as the tables are designed with accessibility in mind. "
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.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
DOM Manipulation is difficult in a table-based layout.
With semantic divs:
$('#myawesomediv').click(function(){
// Do awesome stuff
});
With tables:
$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});
Now, granted, the second example is kind of stupid, and you can always apply IDs or classes to a table or td element, but that would be adding semantic value, which is what table proponents so vehemently oppose.
When I design my layout using CSS, I generally give every major section its own root (body level) div, and use relative/absolute positioning to get it into its proper place. This is a bit more flexible than tables, as I'm not limited to an arrangement that I can represent using rows and columns.
Furthermore, if I decide that I want to rearrange the layout (say I want the navigation bar to be on the right now) I can simply go and alter the position for the elements in one place (the CSS file) and the HTML doesn't have to change. If I were doing that with tables, I would have to go in and find the information and do a lot of attribute modding and copying and pasting to get the same effect.
In fact, using CSS, I can even have my users select how they want their layout to work. So long as the general size of the content areas doesn't change, I'm perfectly OK with using a bit of PHP scripting to output my CSS based on user preferences, and allowing them to rearrange the site to their own liking. Once again, possible with tables, but much much harder to maintain.
Finally, CSS allows one MAJOR benefit that tables will never provide: the ability to reformat content based on the display device. CSS allows me to use a completely different style set (including position, formatting, etc) for a printer than the one I use for the monitor. This can be extended to other media as well, an excellent example is Opera Show, which allows a cleverly designed (and very standard) CSS enhanced page to be viewed as a slide show.
So in the end, flexibility and management are the real winners. Generally, CSS allows you to do more with the layout. There's nothing technically nonstandard about a table based layout, but why would you want to limit yourself?
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.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
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.)
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.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
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.
I once learned that a table loads at once, in other words when a connection is slow, the space where the table comes remains blank until the entire table is loaded, a div on the other hand loads top to bottom as fast as the data comes and regardless if it is allready complete or not.
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.
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.
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.
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.)
1: Yes, your users do care. If they use a screen reader, it will be lost. If I use any other tool which tries to extract information from the page, encountering tables that aren't used to represent tabular data is misleading.
A div or span is acceptable for separating content because that is precisely the meaning of those elements. When I, a search engine, a screen reader or anything else, encounter a table element, we expect that this means "the following is tabular data, represented in a table". When we encounter a div, we expect "this is an element used to divide my content into separate parts or areas.
2: Readability: Wrong. If all the presentation code is in css, I can read the html and I'll understand the content of the page. Or I can read the css and understand the presentation. If everything is jumbled together in the html, I have to mentally strike out all the presentation-related bits before I can even see what is content and what isn't. Moreover, I'd be scared to meet a web developer who didn't understand css, so I really don't think that is an issue.
3: Tables are slower: Yes, they are. The reason is simple: Tables have to be parsed completely, including their contents before they can be rendered. A div can be rendered when it is encountered, even before its contents have been parsed. That means divs will show up before the page has finished loading.
And then there's the bonus, that tables are much more fragile, and won't always be rendered the same in different browsers, with different fonts and font sizes and all the other factors that can cause layout to vary. Tables are an excellent way to ensure that your site will be off by a pixel or two in certain browsers, won't scale well when the user changes his font size, or changes his settings in any other way.
Of course #1 is the big one. A lot of tools and applications depend on the semantic meaning of a webpage. The usual example is screen-readers for visually impaired users. If you're a web developer, you'll find that many large companies who may otherwise hire you to work on a site, require that the site is accessible even in this case. Which means you have to think about the semantic meaning of your html. With the semantic web, or more relevantly, microformats, rss readers and other tools, your page content is no longer viewed exclusively through a browser.
</table> element.I try to avoid TABLEs as much as possible, but when we are designing complex forms that mix multiple control types and different caption positions with pretty strict controls on grouping, using DIVs is unreliable or often near impossible.
Now, I will not argue that these forms could not be redesigned to better accommodate a DIV based layout, but for some of them our customer is adamant about not changing the existing layouts from the previous version (written in classic ASP) because it parallels a paper form that their users are familiar with.
Because the presentation of the forms is dynamic (where the display of some sections is based on the state of the case or the permissions of the user), we use sets of stacked DIVs, each containing a TABLE of logically grouped form elements. Each column of the TABLE is classed so that they can be controlled by CSS. That way we can turn off different sections of the form without the problem of not being table to wrap rows in DIVs.
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
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.
Surely the OP was a bit of a wind up, the arguments seem so week and easily countered.
Web pages are the domain of web developers, and if they say div & CSS is better than tables that's good enough for me.
If a layout is achieved by tables generated by a server app, then a new layout means changes to the app, a rebuild and redelpoy of the application, as apposed to just changes to a css file.
Plus, accessibility. Tables used for layout make a website inaccessible, so don't use them. It's a no brainer, not to mention illegal.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
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.
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
One example: you want to center the main content area of a page, but in order to contain the floats inside it, it needs to be floated. There is no "float: center" in CSS.
That is not the only way to "contain the floats" inside a centred element. So, not a good argument at all!
In a way, it's a false premise, the "divs vs tables" thing.
Quick-and-dirty division of a page into three columns? Tables are easier, to be honest. But no professional uses them any more for layout, because they lock the positioning of page elements into the page.
The real argument is "positioning done by CSS (hopefully in a remote file)" as opposed to "positioning done by HTML in the page". Surely everyone can see the benefits of the former as opposed to the latter?
Consider this:
[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]
which represents two rows of a table with 6 cells. Someone who can see the 2-D table layout will see a caption under each picture. But using speech synthesis, or a PDA, and for a search engine spider, that's
picture picture picture caption caption caption
and the relationship, which is obvious with the table in place, disappears.
Are DIVs and CSS better for the task of simply laying out rectangles on an HTML page to achieve a given design in the shortest possible time? No, they're probably not. But I'm not in the business of quickly laying out rectangles to achieve a given design. I'm thinking of a much bigger picture.
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.
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.)
Tables used as pure layout does pose some problems for accessability (that I've heard). But I understand what is being asked here that somehow you're crippling the web by using a table to ensure correct alignment of something on your page.
I've heard people argue before that FORM labels and inputs are, in fact, data and that they should be allowed into tables.
The argument that using a table to make sure a few elements line up correctly causes this massive increase in code tend to include examples of how a single DIV can meet all their needs. They don't always include the 10 lines of CSS and special browser hacks they had to write for IE5,IE5.5,IE6,IE7...
I think it remains about using balance in your design. Tables are in the toolbox, just remember what they are for...
Flex has a tag for laying things out in vertical columns. I don't think they got the whole layout/content thing right either to be honest, but at least they've resolved that issue.
Like many of the people frustrated with CSS I've also looked far and wide for an easy answer, was duped into feeling elated when I thought I had found it, and then had my hopes dashed to pieces when I opened the page in Chrome. I'm definitely not skilled enough to say it's not possible, but I haven't seen anyone offer up sample code for peer review proving unequivocally that it can be done reliably.
So can someone from the CSS side of this island recommend a mindset/methodology for laying out vertical columns? I've tried absolute positioning in second and third rows, but i end up with stuff overlapping everywhere and float has similar issues if the page is shrunk down.
If there was an answer to this I'd be ecstatic to -do the right thing- Just tell me something like, "Hey have you tried **flow:vertical|horizontal" and I'm totally out of your hair.
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.
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.
If you're supporting the table angle on this find a site with tables and then get yourself a screenreader - set off the screen reader and turn off your monitor.
Then try it with a nice semantically correct div layout site.
You'll see the difference.
Tables aren't evil if the data in them is tabular not to layout the page.
The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.
For simple layout issues why not bend the rule that says presentation must be completely separate? What about a new tag (or some extension to the div tag) that allows us to control presentation directly in HTML? After all, aren't we already leaking presentation into HTML? Look at h1, h2...h6. We all know these control presentation.
The ability to read code (and HTML is code) is very important. Gurus tend to overlook how important it is to make a programming environment as accessible to the masses as possible. It is very shortsighted to think that only professional programmers matter.
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
It doesn't have to be a war. Harmony is possible.
Use one table for the overall layout and divs inside it.
<table>
<tr><td colspan="3"><div>Top content</div></td></tr>
<tr>
<td><div>Left navigation</div></td>
<td><div>Main content</div></td>
<td><div>Right navigation</div></td>
</tr>
<tr><td colspan="3"><div>Bottom content</div></td></tr>
</table>
Look - no nested tables.
I have read so many articles on how to achieve this with divs but have never found anything that works every time with no issues.
Divs are great once you have the overall structure but quite frankly, fluid header/footer and three fluid columns is a total pain in divs. Divs weren't designed for fluidity so why use them?
Note that this approach will give you 100 % CSS compliance at link text
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.
When I design my layout using CSS, I generally give every major section its own root (body level) div, and use relative/absolute positioning to get it into its proper place. This is a bit more flexible than tables, as I'm not limited to an arrangement that I can represent using rows and columns.
Furthermore, if I decide that I want to rearrange the layout (say I want the navigation bar to be on the right now) I can simply go and alter the position for the elements in one place (the CSS file) and the HTML doesn't have to change. If I were doing that with tables, I would have to go in and find the information and do a lot of attribute modding and copying and pasting to get the same effect.
In fact, using CSS, I can even have my users select how they want their layout to work. So long as the general size of the content areas doesn't change, I'm perfectly OK with using a bit of PHP scripting to output my CSS based on user preferences, and allowing them to rearrange the site to their own liking. Once again, possible with tables, but much much harder to maintain.
Finally, CSS allows one MAJOR benefit that tables will never provide: the ability to reformat content based on the display device. CSS allows me to use a completely different style set (including position, formatting, etc) for a printer than the one I use for the monitor. This can be extended to other media as well, an excellent example is Opera Show, which allows a cleverly designed (and very standard) CSS enhanced page to be viewed as a slide show.
So in the end, flexibility and management are the real winners. Generally, CSS allows you to do more with the layout. There's nothing technically nonstandard about a table based layout, but why would you want to limit yourself?
</table> element.WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
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.
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.
To respond to the "tables are slower" argument - you're thinking rendering time, which is the wrong metric. Very often, developers will write out a huge table to do the entire layout for a page - which adds significantly to the size of the page to be downloaded. Like it or not, there's still a ton of dialup users out there.
See also: overusing ViewState
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.
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.
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.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
Tables are good for HTML that you're throwing together for something simple or temporary. If you're building a large-scale website, you should go with divs and CSS, since it will be easier to maintain over time as your website changes.
The issue of strictly separating presentation and content strikes me as roughly analogous to separating header files from implementation files in C++. It makes sense, but it can also be a pain. Witness Java and C# where classes are defined in a single source file. The authors of the newer languages noticed something that was causing programmers headaches and they got rid of it. That seems to be the gist of this discussion. One side is saying CSS is too difficult, the other side is saying one must become a CSS master.
For simple layout issues why not bend the rule that says presentation must be completely separate? What about a new tag (or some extension to the div tag) that allows us to control presentation directly in HTML? After all, aren't we already leaking presentation into HTML? Look at h1, h2...h6. We all know these control presentation.
The ability to read code (and HTML is code) is very important. Gurus tend to overlook how important it is to make a programming environment as accessible to the masses as possible. It is very shortsighted to think that only professional programmers matter.
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.
I still don't quite understand how divs / CSS make it easier to change a page design when you consider the amount of testing to ensure the changes work on all browsers, especially with all the hacks and so on. Its a hugely frustrating and tedious process which wastes large amounts of time and money.
Thankfully the 508 legislation only applies to the USA (land of the free - yeah right) and so being as I am based in the UK, I can develop web sites in whatever style I choose. Contrary to popular (US) belief, legislation made in Washington doesn't apply to the rest of the world - thank goodness for that. It must have been a good day in the world of web design the day the legislation came into force.
I think I'm becoming increasingly cynical as I get older with 25 years in the IT industry but I feel sure this kind of legislation is just to protect jobs. In reality anyone can knock together a reasonable web page with a couple of tables. It takes a lot more effort and knowledge to do this with DIVs / CSS. In my experience it can take hours and hours Googling to find solutions to quite simple problems and reading incomprehensible articles in forums full of idealistic zealots all argueing about the 'right' way to do things. You can't just dip your toe in the water and get things to work properly in every case. It also seems to me that the lack of a definitive guide to using DIVS / CSS "out of the box", that applies to all situations, working on browsers, and written using 'normal' language with no geek speak, also smells of a bit of protectionism.
I'm an application developer and I would say it takes almost twice as long to figure out layout problems and test against all browsers than it does to create the basic application, design and implement business objects, and create the database back end. My time = money, both for me and my customers alike so I am sorry if I don't reject all the pro DIV / CSS arguments in favour of cutting costs and providing value for money for my customers. Maybe its just the way that developers minds work, but it seems to me far easier to change a complex table structure than it is to modify DIVs / CSS.
Thankfully it now appears that a solution to these issues is now available - its called WPF.
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.
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.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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!
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
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.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
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.
A huge issue for me is that tables, especially nested tables, take much longer to render than a properly layed out css implementation. (You can make css just as slow).
All browsers render the css faster because each div is a seperate element, so a screen can be loading as the user is reading. (For huge data sets, etc). I've used css instead of tables in that instance not even dealing with layout.
A nested table (tables inside of cells, etc) will not render to the browser window until the last "/table" is found. Even worse - a poorly defined table will somtimes not even render! Or when it does, things misbehave. (not colspanning properly with "TD"'s etc.)
I use tables for most things, but when it comes to large data and the desire to have a screen render quickly for an end-user - I try my best to utilize what CSS has to offer.
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.
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.
From past experience, I'd have to go for DIV's. Even in OOP, the main aim is to reduce the coupling between objects, so this concept can be applied to DIVS and tables. Tables are used for holding data, not for arranging it around a page. A DIV is specifically designed to arrange items around a page, so the design should use DIV's, tables should be used to store data.
Also, editting websites made with tables is just plain hard (in my opinion)
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.
I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
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've had to do sites in both of those ways, plus a third, the dreaded "hybrid" layout with tables, divs and styles: Divs/CSS wins, handily.
You'd have to nest divs three deep to match the code weight of just one table cell, right off the bat. That effect scales with nested tables.
I'd also prefer to make one layout change, vs one change for every page in my site.
I have full control over every aspect of presentation with divs/css. Tables mess that up in hideous ways, especially in IE, a browser which I have never yet had the option not to support.
My time for maintenance or redesign of a divs/css website is a fraction of what it would be in tables.
Finally, I can innovate multiple, switchable layouts with CSS and virtually any scripting language. That would be impossible for me with tables.
Good luck with your ROI as you make that decision.
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.
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.
As per my knowledge on tables, if too many tables are nested, there is a great overhead to browser in rendering the page.
1 - The browser has wait to render the final view wait until the entire table gets loaded.
2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!
How to optimize tables ? If you're using tables, I would suggest, always define width for the cells. This does not guarantees that browser will blindly take this widths only, but would be of great help to browser in deciding the initial widths.
But, at the end, div are great way as CSS can be cached by the browser; while table aren't cached !
WYSIWYG!!! I can't for the life of me get our designers to stop using nested DIVS and styled by elementID css in templates that are supposed to be used by clients in CMS projects. That's the whole point of a WYSIWYG online editor. You are controlling both the content and the layout at the same time! There is no separation at all in the first place in this scenario. Positioned and styled Divs in some external stylesheet are anathema to the whole idea of WYSIWYG editing. Tables can be seen, rows inserted, cells combined and so on. Good luck trying this with divs in a way that doesn't frustrate users.
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!
div's and CSS positioning allow a more flexible design, leading to easier modification and templating of your web pages.
That said, if you aren't interested in the flexibility then using a table rather than some divs that are morphed into a table by CSS is definitely a lot easier and quicker to knock up. I tend to use tables when knocking up a design just to get it looking right that bit quicker.
In terms of site maintenance and design overhauls while maintaining content (which happen all the time, especially in eCommerce):
Content and design mashed up together via tables = updating both content and design.
Content separate from design = updating design and maybe a little content.
If I had it my way, I'd keep my content in PHP generating XML, converted to markup in XSLT and designed with CSS and Javascript for the interaction. For the Java side of things, JSP to JSTL to generate the markup.
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.
Use tables when you need to ensure that elements need to remain in a specific physical relationship in the layout. For data, the table is generally the best layout element to use because you do not want your columns to wrap in an uxexpected ways and confuse the associations.
One could also argue that non-data elements that must remain in a specific relationship should also be rendered in a table.
Flexible css layouts are great for content that is suitable for mobile devices and large screens and printing and other display types, but sometimes, the content just has to be displayed in a very specific way and if that requires that screen readers cannot easily access it, it could very well be justified.
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.
In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.
The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).
To this end, tabular data, that is to say data that makes logical sense to be ordered in two or more dimensions, with some sort of headers, is best placed in tables, and use divs to manage the layout of content on the page. (another way to think of what "tabular data" is is to try to draw it in graph form...if you can't, it likely is not best represented in a table)
Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.
In both cases, the increase in "last mile" bandwidth, as well as much faster personal computers mitigates these factors, but none-the-less, they still are existing issues for many sites.
With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
Super short answer: designing maintainable websites is difficult with tables, and simple with the standard way to do it.
A website isn't a table, it's a collection of components that interact with each other. Describing it as a table doesn't make sense.
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.
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.
The separation between content and layout makes it also easier to generate printer-friendly layouts or just different skins (styles) for your site, without having to create different html-files. Some browser (like Firefox) even support selecting a stylesheet from the view-menu.
And I do think it's easier to maintain a tableless layout. You don't have to worry about rowspans, colspans, etc. You just create some container-divs and place the content where you need to. And that said I think it also more readable (<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>).
It's just a little 'trick' you have to learn (and once you mastered the trick, I think it's easier and makes more sense).
I think nobody cares how a website was designed/implemented when it behaves great and it works fast.
I use both "table" and "div"/"span" tags in HTML markup.
Let me give you few arguments why I am choosing divs:
for a table you have to write at least 3 tags (table, tr, td, thead, tbody), for a nice design, sometimes you have a lot of nested tables
I like to have components on the page. I don't know how to explain exactly but will try. Suppose you need a logo and this have to be placed, just a small piece of it, over the next page content. Using tables you have to cut 2 images and put this into 2 different TDs. Using DIVs you can have a simple CSS to arange it as you want. Which solution do you like best?
when more then 3 nested tables for doing something I am thinking to redesign it using DIVs
BUT I am still using tables for:
tabular data
content that is expanding self
fast solutions (prototypes), because DIVs box model is different on each browser, because many generators are using tables, etc
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.
Google gives very low priority to text content contained inside a table. I was giving some SEO advice to a local charity. In examining their website it was using tables to layout the site. Looking at each page, no matter what words - or combination of words - from their pages I used in the Google search box the pages would not come up in any of the top search pages. (However, by specifying the site in the search the page was returned.) One page was well copy written by normal standards to produce a good result in a search but still it didn't appear in any of the first pages of search results returned. (Note this text was within a table.) I then spotted a section of text on the pages which was in a div rather than a table. We put a few of the words from that div in the search engine. Result? It came in at No.2 in the search result.
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.
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.
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.
Source: Stackoverflow.com