为什么不在HTML中使用表格进行布局？
似乎普遍认为表格不应该用于HTML中的布局。
为什么？
我从来没有（或者很less说实话）看到这个好的论点。 通常的答案是：
-
从布局分离内容是很好的
但这是一个错误的论点; 陈词滥调 。 我想这是真的，使用表格元素的布局与表格数据很less。 所以呢？ 我的老板照顾吗？ 我的用户关心吗？也许我或我的开发人员必须维护一个网页护理…是不是一个表维护？ 我认为使用表格比使用div和CSS 更容易 。
顺便说一下…为什么要使用div或span来完美地区分布局和表格中的内容呢？ 只有div才能获得良好的布局，往往需要大量的嵌套div。
-
代码的可读性
我认为这是相反的。 大多数人理解HTML，很less理解CSS。 -
SEO最好不要使用表格
为什么？ 任何人都可以certificate这是一个证据吗？ 或从谷歌的声明，从SEO的angular度来看，表格是不鼓励的？ -
表格较慢。
一个额外的tbody元素必须被插入。 这是现代网页浏览器的花生。 给我看一些使用表格显着减慢页面的基准。 -
如果没有桌子，布局检修更容易，请参阅禅宗花园 。
大多数需要升级的网站也需要新的内容（HTML）。 新版本的网站只需要一个新的CSS文件的情况不太可能。 禅园是一个不错的网站，但有点理论。 更不用说它滥用 CSS了。
我真的很感兴趣的是使用div + CSS而不是表格。
我会一个接一个地看看你的观点，并试图展示他们的错误。
将内容与布局分开是很好的但是这是一个错误的论点。 Cliché思维。
这完全不是错误的，因为HTML是有意devise的。 滥用元素可能不完全没有问题（毕竟，其他语言也有新的成语发展），但是可能的负面影响必须抵消。 另外，即使目前没有反对滥用<table>元素的论据，明天可能会有浏览器供应商对元素进行特殊处理的方式。 毕竟，他们知道“ <table>元素仅用于表格数据”，并且可能会利用这个事实来改进渲染引擎，在这个过程中巧妙地改变<table>的行为方式，从而打破以前被滥用的情况。
所以呢？ 我的老板照顾吗？ 我的用户关心吗？
依靠。 你的老板是尖头的吗？ 那么他可能不在乎。 如果她能胜任，那么她会照顾，因为用户会 。
也许我或我的开发人员必须维护一个网页护理…是不是一个表维护？ 我认为使用表格比使用div和css更容易。
大部分的专业网站开发者似乎都反对你 [ 引文需要 ] 。 这些表格实际上不易维护，应该是显而易见的。 使用表格进行布局意味着改变公司布局实际上意味着改变每一个页面。 这可能是非常昂贵的。 另一方面，明智地使用与CSS结合的语义上有意义的HTML 可能会限制对CSS和使用的图片的这种改变。
顺便说一下…为什么要使用div或span来完美地区分布局和表格中的内容呢？ 只有div才能获得良好的布局，往往需要大量的嵌套div。
深度嵌套<div>是一种反模式，就像表格布局一样。 好的网页devise师不需要很多。 另一方面，即使是这样的深层嵌套也没有很多桌面布局的问题。 事实上，他们甚至可以通过对内容进行逻辑划分来实现语义结构。
代码的可读性我认为这是相反的方式。 大多数人都懂html，很less理解CSS。 这很简单。
“大多数人”并不重要。 专业人士的事 对于专业人士来说，表格布局会比HTML + CSS造成更多的问题。 这就像是说我不应该使用GVim或Emacs，因为记事本对于大多数人来说更简单。 或者我不应该使用LaTeX，因为MS Word对于大多数人来说更简单。
SEO最好不要使用表格
我不知道这是否是真实的，不会用这个作为论据，但这是合乎逻辑的。 search引擎search相关数据。 尽pipe表格数据当然可能是相关的，但很less用户search。 用户search页面标题中使用的术语或类似的显着位置。 因此将表格内容从过滤中排除是合乎逻辑的，因此可以大大减less处理时间（和成本！）。
表格较慢。 一个额外的tbody元素必须被插入。 这是现代网页浏览器的花生。
额外的元素与表格速度没有任何关系。 另一方面，表格的布局algorithm要困难得多，浏览器在开始布局内容之前通常需要等待整个表格的加载。 另外，caching布局将不起作用（CSS可以很容易地被caching）。 所有这些都是之前提到的。
给我看一些使用表格显着减慢页面的基准。
不幸的是，我没有任何基准数据。 我会自己感兴趣的，因为这个论点缺乏一定的科学严谨性是正确的。
大多数需要升级的网站也需要新的内容（html）。 新版本的网站只需要一个新的css文件的情况不太可能。
一点也不。 我曾经在几个案例中对内容和devise进行了分离，从而简化了devise。 通常仍然需要更改一些HTML代码，但是更改总是会受到更多的限制。 另外，devise更改必须有时dynamic地进行。 考虑模板引擎，如WordPress博客系统使用的模板引擎。 表格布局会从字面上杀死这个系统。 我为一个商业软件工作过类似的案例。 能够改变devise而不改变HTML代码是业务需求之一。
另一件事。 表格布局使得网站的自动parsing（屏幕抓取）变得更加困难。 这可能听起来微不足道，因为毕竟是谁做的？ 我很惊讶自己。 如果有问题的服务没有提供访问其数据的WebService替代方法，则屏幕抓取可以提供很多帮助。 我在生物信息学工作，这是一个可悲的现实。 现代networking技术和Web服务还没有达到大多数开发人员，并且屏幕抓取是自动获取数据的唯一方法。 难怪许多生物学家仍然手动执行这些任务。 成千上万的数据集。
这是我的程序员从一个simliar线程 的答案
语义学101
首先看看这个代码，想想这里有什么问题…
class car { int wheels = 4; string engine; } car mybike = new car(); mybike.wheels = 2; mybike.engine = null;
问题当然是，自行车不是汽车。 汽车类是自行车实例的不适当的类。 该代码没有错误，但在语义上是不正确的。 它对程序员反映不佳。
语义学102
现在将其应用于文档标记。 如果您的文档需要显示表格数据，那么相应的标签就是<table> 。 但是，如果将导航放置到表中，则会滥用<table>元素的预期用途。 在第二种情况下，你不是呈现表格数据 – 你（错）使用<table>元素来实现一个表象的目标。
结论
游客会注意到吗？ 不，你的老板在乎吗？ 也许。 我们有时候像程序员一样偷工减料吗？ 当然。 但是，我们应该？ 不，如果您使用语义标记，谁会受益？ 你 – 和你的专业声誉。 现在去做正确的事情。
明显的答案：请参阅CSS禅园 。 如果你告诉我，你可以轻松地做一个基于表格的布局（记住 – HTML不会改变），那么通过所有的方式来使用表格布局。
另外两个重要的事情是可访问性和SEO。
他们都关心信息呈现的顺序。 如果基于表格的布局将其放在页面上第二个嵌套表格的第二行的第三个单元格中，则无法在页面顶部轻松呈现导航。
所以你的答案是可维护性，可访问性和SEO。
不要懒惰。 即使学习有点困难，也要做正确而恰当的事情。
看到这个重复的问题。
一个你忘记的项目是无障碍的。 例如，如果您需要使用屏幕阅读器，基于表格的布局也不会翻译。 如果你为政府工作，可能需要支持可访问的浏览器，如屏幕阅读器。
我也认为你低估了你提到的一些问题的影响。 例如，如果您既是devise人员又是程序员，则您可能不完全了解将演示文稿与内容分开的程度。 但一旦你进入一个两个不同angular色的商店，优势就会变得更加清晰。
如果你知道自己在做什么，并且有很好的工具，CSS确实比布局表具有更多优势。 虽然每个项目本身可能不合理放弃表格，但总体来说，这是值得的。
不幸的是，CSS Zen Garden不能再被用作良好的HTML / CSSdevise的例子。 几乎所有他们最近的devise使用graphics的部分标题。 这些graphics文件是在CSS中指定的。
因此，一个网站的目的是显示保持内容devise的优势，现在定期承诺把内容放入devise的不可思议的事实。 （如果HTML文件中的标题部分发生更改，则显示的部分标题不会显示）。
这只能说明，即使那些提倡严格的DIV和CSS宗教，也不能遵循自己的规则。 你可以用它作为指导你如何密切关注他们。
这不是一个明确的论点，但是对于CSS，你可以采用相同的标记，并根据媒介改变布局，这是一个很好的优势。 例如，对于打印页面，您可以悄悄地禁止导航，而无需创build打印机友好的页面。
一个布局表不会那么糟糕。 但是大部分时间只用一张桌子就无法获得所需的布局。 很快你有两个或三个嵌套表。 这变得非常麻烦。
-
这是一个很难阅读。 这不符合意见。 只有更多的嵌套标签，没有识别标记。
-
将内容与演示文稿分开是一件好事，因为它可以让你专注于你正在做的事情。 将两条导线混合到难以阅读的臃肿页面。
-
样式CSS允许您的浏览器caching文件和后续请求要快得多。 这是巨大的。
-
桌子locking你的devise。 当然，不是每个人都需要CSS Zen Garden的灵活性，但是我从来没有在一个网站上工作过，因为我不需要在这里或那里稍微改变一下devise。 使用CSS更容易。
-
桌子很难风格。 你没有太多的灵活性（即你仍然需要添加HTML属性来完全控制表格的样式）
大概4年我没有使用非表格数据表。 我没有回头。
我真的想build议读安迪·巴德的CSS通达 。 这是梦幻般的。
ecx.images-amazon.com图片http://ecx.images-amazon.comhttp://img.dovov.comI/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45,-64_OU01_AA240_SH20_.jpg
从布局分离内容是很好的
但这是一个错误的论点; 陈词滥调
这是一个错误的论点，因为HTML表格是布局！ 内容是表格中的数据 ，表示是表格本身。 这就是为什么从HTML分离CSS有时会非常困难。 您不是将内容与演示文稿分开，而是将演示文稿与演示文稿分开！ 一堆嵌套的div与表格没有什么不同，它只是一组不同的标签。
将CSS与CSS分开的另一个问题是，他们需要彼此深入的了解 – 你实在无法完全分离它们。 无论您做什么，HTML中的标签布局都与CSS文件紧密结合。
我认为表格和divs可以归结为您的应用程序的需求。
在我们开发的应用程序中，我们需要一个页面布局，其中的各个部分将dynamicresize以适应其内容。 我花了好几天的时间试图让这个CSS和DIV跨浏览器工作，这是一个完整的噩梦。 我们切换到表，这一切工作 。
但是，我们的产品（我们销售一个带有Web界面的硬件）的受众非常密集，可访问性问题不是我们关心的问题。 我不知道为什么屏幕阅读器不能很好地处理表格，但是我想如果是这样的话，开发人员必须要处理它。
CSS / DIV – 这只是devise男生的工作，不是吗？ 我花了几百个小时来debuggingDIV / CSS问题，search互联网以获取标记的一部分与一个模糊的浏览器工作 – 这让我发疯。 你做了一点小小的改变，整个布局变得非常糟糕 – 在哪里就是逻辑。 花几个小时移动3像素这样的东西，然后其他2像素的另一个让他们全部排队。 不知怎的，这似乎显然是错误的。 仅仅因为你是一个纯粹主义者，某种东西“不是正确的事情”并不意味着你应该利用它到第n个等级，在任何情况下，特别是如果它使你的生活容易1000倍。
所以，我终于决定，纯粹从商业angular度来说，尽pipe我保持最低限度的使用，如果我预计20小时工作，以正确地放置DIV，我会坚持在桌子上。 这是错误的，它扰乱纯粹主义者，但在大多数情况下，它花费更less的时间，更便宜的pipe理。 然后，我可以专注于让应用程序按客户要求工作，而不是让纯粹主义者满意。 他们的确支付了账单，而我的理由就是强制使用CSS / DIV的经理 – 我只想指出客户也支付了他的工资！
所有这些CSS / DIV论点发生的唯一原因是由于CSS的缺点，因为浏览器彼此不兼容，如果是这样的话，世界上一半的网页devise师将会失业。
当你devise一个Windows窗体时，你不要在你把它们放好之后试着移动控件，所以我觉得我很奇怪你为什么要用一个web窗体来做这个。 我根本无法理解这个逻辑。 先从版面devise开始，问题是什么。 我认为这是因为devise师喜欢调情创意，而应用程序开发人员更关心的是真正实现应用程序的工作，创build业务对象，实现业务规则，研究客户数据如何相互关联，确保客户满足客户要求 – 你知道 – 像现实世界的东西。
不要误会我的意思，这两个论点都是有效的，但请不要批评开发者select更简单，更合乎逻辑的方式来devise表单。 我们经常有更重要的事情比在div上使用表的正确语义更令人担心。
举个例子 – 基于这个讨论，我把一些现有的tds和trs转换成了divs。 45分钟搞砸了，试图让所有东西排成一排，我放弃了。 TDs在10秒后回来 – 直接运行 – 在所有的浏览器上，没有什么可做的了。 请尽量让我明白 – 你有什么可能的理由要求我做任何其他的方式！
布局应该很容易。 有关如何在CSS中实现带有页眉和页脚的dynamic三列布局的文章显示这是一个糟糕的布局系统。 当然，你可以把它运作起来，但是在网上有几百篇关于如何去做的文章。 几乎没有这样的文章与表格类似的布局，因为它是明显的。 无论你对桌面和CSS支持怎么说，这个事实都可以解决这个问题：CSS中的基本三列布局通常被称为“圣杯”。
如果这样做不能让你说“跆拳道”，那么你现在真的需要放弃这个驴友。
我喜欢CSS。 它提供了惊人的造型选项和一些很酷的定位工具，但作为一个布局引擎是不足的。 需要有一些types的dynamic网格定位系统。 一个简单的方法来alignment多轴上的方框，而不必先知道它们的尺寸。 如果你把它叫做<table>或者<gridlayout>或者别的什么，我都不会这么做，但是这是CSS中缺less的一个基本的布局特性。
更大的问题是，由于不承认有缺失的function，CSS狂热者已经从所有可能的CSS拿回CSS。 如果CSS提供像世界上其他任何布局引擎一样好的多轴网格定位，我将非常高兴停止使用表格。 （你已经意识到这个问题已经被除了W3C以外的所有人用多种语言解决了很多次，对吧？没有人否认这个function是有用的。）
叹。 足够的通风。 继续前进，把头靠在沙滩上。
根据508合规性（对于视觉障碍的屏幕阅读器），表格只能用于保存数据而不用于布局，因为它会导致屏幕阅读器出现exception。 或者我被告知。
如果您为每个div分配名称，则可以使用CSS将它们全部绑定在一起。 他们只是更多地坐在你需要的方式上。
这里是一个最近的项目的HTML部分：
<?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>
这是与基于表格的布局相同的代码。
<?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>
我在这种基于表格的布局中看到的唯一清洁工作就是我对缩进的过度热情。 我相信内容部分会有另外两个embedded表格。
另一个要考虑的事情是： 文件大小 。 我发现基于表格的布局通常是CSS对应格式的两倍。 在我们的高速宽带上，这不是一个大问题，而是拨号调制解调器的问题。
I'd like to add that div-based layouts are easer to mantain, evolve, and refactor. Just some changes in the CSS to reorder elements and it is done. From my experience, redesign a layout that uses tables is a nightmare (more if there are nested tables).
Your code also has a meaning from a semantic point of view.
No arguments in DIVs favour from me.
I'd say : If the shoe fits, wear it.
It's worth noting that it's difficult if not impossible to find a good DIV+CSS method of rendering contents in two or three columns, that is consistent on all browsers, and still looks just the way I intended.
This tips the balance a bit towards tables in most of my layouts, and altough I feel guilty of using them (dunny why, people just say it's bad so I try to listen to them), in the end , the pragmatic view is it's just easier and faster for me to use TABLEs. I'm not being payed by the hour, so tables are cheaper for me.
CSS layouts are generally much better for accessibility, provided the content comes in a natural order and makes sense without a stylesheet. And it's not just screen readers that struggle with table-based layouts: they also make it much harder for mobile browsers to render a page properly.
Also, with a div-based layout you can very easily do cool things with a print stylesheet such as excluding headers, footers and navigation from printed pages – I think it would be impossible, or at least much more difficult, to do that with a table-based layout.
If you're doubting that separation of content from layout is easier with divs than with tables, take a look at the div-based HTML at CSS Zen Garden , see how changing the stylesheets can drastically change the layout, and think about whether you could achieve the same variety of layouts if the HTML was table based… If you're doing a table-based layout, you're unlikely to be using CSS to control all the spacing and padding in the cells (if you were, you'd almost certainly find it easier to use floating divs etc. in the first place). Without using CSS to control all that, and because of the fact that tables specify the left-to-right and top-to bottom order of things in the HTML, tables tend to mean that your layout becomes very much fixed in the HTML.
Realistically I think it's very hard to completely change the layout of a div-and-CSS-based design without changing the divs a bit. However, with a div-and-CSS-based layout it's much easier to tweak things like the spacing between various blocks, and their relative sizes.
The fact that this is a hotly debated question is a testament to the failure of the W3C to anticipate the diversity of layout designs which would be attempted. Using divs+css for semantically-friendly layout is a great concept, but the details of implementation are so flawed that they actually limit creative freedom.
I attempted to switch one of our company's sites from tables to divs, and it was such a headache that I totally scrapped the hours of work I had poured into it and went back to tables. Trying to wrestle with my divs in order to gain control of vertical alignment has cursed me with major psychological issues that I will never shake as long as this debate rages on.
The fact that people must frequently come up with complex and ugly workarounds to accomplish simple design goals (such as vertical alignment) strongly suggests that the rules are not nearly flexible enough. If the specs ARE sufficient, then why do high-profile sites (like SO) find it necessary to bend the rules using tables and other workarounds?
I guess it's true that using the table element for layout has little to do with tabular data. 所以呢？ Does my boss care? Do my users care?
Google and other automated systems do care, and they're just as important in many situations. Semantic code is easier for a non-intelligent system to parse and process.
Having had to work with a website that involved 6 layers of nested tables generated by some application, and having had it generate invalid HTML, it was in fact a 3 hour job to rectify it breaking for a minor change.
This is of course the edge case, but table based design is unmaintainable. If you use css, you separate the style out so when fixing the HTML you have less to worry about breaking.
Also, try this with JavaScript. Move a single table cell from one place to another place in another table. Rather complicated to perform where div/span would just work copy-paste-wise.
"Does my boss care"
If I were your boss. You would care. 😉 If you value your life.
Layout flexibility
Imagine you're making a page with a large number of thumbnails.
DIVs :
If you put each thumbnail in a DIV, floated left, maybe 10 of them fit on a row. Make the window narrower, and BAM – it's 6 on a row, or 2, or however many fit.
TABLE:
You have to explicitly say how many cells are in a row. If the window is too narrow, the user has to scroll horizontally.
Maintainability
Same situation as above. Now you want to add three thumbnails to the third row.
DIVs:
Add them in. The layout will automatically adjust.
TABLE: Paste the new cells into the third row. 哎呀！ Now there are too many items there. Cut some from that row and put them on the fourth row. Now there are too many items there. Cut some from that row… (etc)
( Of course, if you're generating the rows and cells with server-side scripting, this probably won't be an issue. )
I think that boat has sailed. If you look at the direction the industry has taken you will notice that CSS and Open Standards are the winners of that discussion. Which in turn means for most html work, with the exception of forms, the designers will use divs instead of tables. I have a hard time with that because I am not a CSS guru but thats the way it is.
Also, don't forget, tables don't quite render well on mobile browsers. Sure, the iPhone has a kick-ass browser but everyone doesn't have an iPhone. Table rendering can be peanuts for modern browsers, but it's a bunch of watermelons for mobile browsers.
I have personally found that many people use too many <div> tags, but in moderation, it can be extremely clean and easy to read. You mention that folks have a harder time reading CSS than tables; in terms of 'code' that maybe true; but in terms of reading content (view > source) it is a heck of a lot easier to understand the structure with stylesheets than with tables.
Looks like you are just used to tables and that's it. Putting layout in a table limits you for just that layout. With CSS you can move bits around, take a look at http://csszengarden.com/ And no, layout does not usally require a lot of nested divs.
With no tables for layout and proper semantics HTML is much cleaner, hence easier to read. Why should someone who cannot understand CSS try to read it? And if someone considers himself to be webdeveloper then the good grasp of CSS is a must.
SEO benefits come from the ability to have most important content higher up the page and having better content-to-markup ratio.
- 508 Compliance – the ability for a screenreader to make sense of your markup.
- Waiting for render – tables don't render in the browser until it gets to the end of the
</table>element.
The whole idea around semantic markup is the separation of markup and presentation, which includes layout.
Div's aren't replacing tables, they have their own use in separating content into blocks of related content (, ). When you don't have the skills and are relying on tables, you'll often have to separate your content in to cells in order to get the desired layout, but you wont need to touch the markup to achieve presentation when using semantic markup. This is really important when the markup is being generated rather than static pages.
Developers need to stop providing markup that implies layout so that those of us who do have the skills to present content can get on with our jobs, and developers don't have to come back to their code to make changes when presentation needs change.
This isn't really about whether 'divs are better than tables for layout'. Someone who understands CSS can duplicate any design using 'layout tables' pretty straightforwardly. The real win is using HTML elements for what they are there for. The reason you would not use tables for non-tablular data is the same reason you don't store integers as character strings – technology works much more easily when you use it for the purpose for which it is desgined. If it was ever necessary to use tables for layout (because of browser shortcomings in the early 1990s) it certainly isn't now.
Tools that use table layouts can become extraordinarily heavy due to the amount of code required to create the layout. SAP's Netweaver Portal by default uses TABLE to layout their pages.
The production SAP portal at my current gig has a home page whose HTML weighs over 60K and goes seven tables deep, three times within the page. Add in the Javascript, the misuse of 16 iframes with similar table issues inside of them, overly heavy CSS etc, and the page weighs over 5MB.
Taking the time to lower the page weight so you can use your bandwidth to do engaging activities with users is worth the effort.
It's worth figuring out CSS and divs so the central content column loads and renders before the sidebar in a page layout. But if you are struggling to use floating divs to vertically align a logo with some sponsorship text, just use the table and move on with life. The Zen garden religion just doesn't give much bang for the buck.
The idea of separating content from presentation is to partition the application so different kinds of work affect different blocks of code. This is actually about change management. But coding standards can only examine the present state of code in a superficial manner.
The change log for an application that depends on coding standards to "separate content from presentation" will show a pattern of parallel changes across vertical silos. If a change to "content" is always accompanied by a change to "presentation", how successful is the partitioning?
If you really want to partition your code productively, use Subversion and review your change logs. Then use the simplest coding techniques — divs, tables, JavaScript, includes, functions, objects, continuations, whatever — to structure the application so that the changes fit in a simple and comfortable manner.
Because it's HELL to maintain a site that uses tables, and takes a LOT longer to code. If you're scared of floating divs, go take a course in them. They're not difficult to understand and they're approximately 100 times more efficient and a million times less a pain in the ass (unless you don't understand them — but hey, welcome to the world of computers).
Anyone considering doing their layout with a table better not expect me to maintain it. It's the most ass-backwards way to render a website. Thank god we have a much better alternative now. I would NEVER go back.
It's scary that some folks might not be aware of the time and energy benefits from creating a site using modern tools.
Tables are not in general easier or more maintainable than CSS. However, there are a few specific layout-problems where tables are indeed the simplest and most flexible solution.
CSS is clearly preferable in cases where presentational markup and CSS support the same kind of design, no one in their right mind would argue that font -tags are better than specifying typography in CSS, since CSS gives you the same power than font -tags, but in a much cleaner way.
The issue with tables, however, is basically that the table-layout model in CSS is not supported in Microsoft Internet Explorer. Tables and CSS are therefore not equivalent in power. The missing part is the grid-like behavior of tables, where the edges of cells align both vertically and horizontally, while cells still expand to contain their content. This behavior is not easy to achieve in pure CSS without hardcoding some dimensions, which makes the design rigid and brittle (as long as we have to support Internet Explorer – in other browsers this is easliy achieved by using display:table-cell ).
So it's not really a question of whether tables or CSS is preferable, but it is a question of recognizing the specific cases where use of tables may make the layout more flexible.
The most important reason for not using tables is accessibility. The Web Content Accessibility Guidelines http://www.w3.org/TR/WCAG10/ advice againt using tables for layout. If you are concerned about accessibility (and in some cases you may be legally obliged to), you should use CSS even if tables are simpler. Note that you can always create the same layout with CSS as with tables, it might just require more work.
I was surprised to see some issues were not already covered, so here are my 2 cents, in addition to all the very valid points made earlier:
.1. CSS & SEO:
a) CSS used to have a very significant impact on SEO by allowing to position the content in the page wherever you want. A few years ago, Search Engines were giving a significant emphasis to "on-page" factors. Something at the top of the page was deemed more relevant to the page than something located at the bottom. "Top of the page" for a spider meant "at the beginning of the code". Using CSS, you could organize your keyword-rich content at the beginning of the code, and still position it wherever you liked in the page. This is still somewhat relevant, but on page factors are less and less important for page ranking.
b) When the layout is moved over to CSS, the HTML page is lighter and therefore loads faster for a search engine spider. (spiders don't bother downloading external css files). Fast loading pages is an important ranking consideration for several search engines, including Google
c) SEO work often requires testing and changing things, which is much more convenient with a CSS based layout
.2. Generated content:
A table is considerably easier to generate programmically than the equivalent CSS layout.
foreach ($comment as $key=>$value) { echo "<tr><td>$key</td><td>$value</td></tr>"; }
Generating a table is simple and safe. It is self-contained and integrates well within any template. To do the same with CSS is considerably harder and may be of no benefit at all: hard to edit the CSS stylesheet on the flight, and adding the style inline is no different from using a table (content is not separated from layout).
Further, when a table is generated, the content (in variables) is already separated from the layout (in code), making it as easy to modify.
This is one reason why some very well designed websites (SO for instance) still use table layouts.
Of course, if the results need to be acted upon through JavaScript, divs are worth the trouble.
.3. Quick conversion testing
When figuring out what works for a specific audience, it is useful to be able to change the layout in various ways to figure out what gets the best results. A CSS based layout makes things considerably easier
.4. Different solutions for different problems
Layout tables are usually dissed because "everybody knows divs & CSS" are the way to go.
However the fact remains that tables are faster to create, easier to understand and are more robust than most CSS layouts. (Yes, CSS can be as robust, but a quick look through the net on different browsers and screen resolutions shows it's not often the case)
There are a lot of downsides to tables, including maintenance, lack of flexibility… but let's not throw the baby with the bath water. There are plenty of professional uses for a solution which is both quick and reliable.
Some time ago, I had to rewrite a clean and simple CSS layout using tables because a significant portion of the users would be using an older version of IE with really bad support for CSS
I, for one, am sick and tired of the knee-jerk reaction "Oh noes! Tables for layout!"
As for the "it wasn't intended for that purpose and therefore you shouldn't use it this way" crowd, isn't that hypocrisy? What do you think of all the CSS tricks you have to use to get the darn thing working in most browsers? Were they meant for that purpose?
;){kind=link}