看起来你只是习惯了桌子，仅此而已。 将布局放在表格中会限制你的布局。用CSS你可以移动位，看看http://csszengarden.com/ 不，布局通常不需要很多嵌套的div。

没有表格的布局和适当的语义HTML更干净，因此更容易阅读。 为什么不理解CSS的人要尝试阅读它呢?如果有人认为自己是web开发人员，那么对CSS的良好掌握是必须的。

SEO的好处来自于将最重要的内容放在页面上方的能力 拥有更好的内容与标记比率。

http://www.hotdesign.com/seybold/

对我来说，一个巨大的问题是，表，特别是嵌套表，需要更长的时间来呈现比一个正确布局的css实现。(你可以让css一样慢)。

所有浏览器呈现css的速度都更快，因为每个div都是一个单独的元素，所以用户在阅读时可以加载屏幕。(对于庞大的数据集等)。我在那个实例中使用了css而不是表格，甚至没有处理布局。

嵌套的表(单元格中的表等)直到找到最后一个“/table”才会呈现到浏览器窗口。更糟糕的是，定义不清的表有时甚至无法呈现!或者当它发生的时候，事情就会不正常。(没有正确地与“TD”等共进)

我在大多数情况下使用表格，但当涉及到大数据和希望为最终用户快速呈现屏幕时，我尽最大努力利用CSS所提供的东西。

对于为了简单或临时的东西而拼凑在一起的HTML，表很有用。如果你正在构建一个大型网站，你应该使用div和CSS，因为随着时间的推移，随着网站的变化，它将更容易维护。

显而易见的答案:参见CSS Zen Garden。如果你告诉我你可以很容易地用基于表格的布局做同样的事情(记住- HTML没有改变)，那么无论如何都要使用表格来布局。

另外两个重要的事情是可访问性和搜索引擎优化。

两者都关心信息以何种顺序呈现。如果基于表格的布局将导航放在页面上第二个嵌套表格的第2行的第3个单元格中，则无法轻松地将导航显示在页面顶部。

所以你的答案是可维护性，可访问性和SEO。

不要偷懒。即使事情有点难学，也要用正确的方式去做。

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).

为此，表格式数据，也就是逻辑上有意义的在二维或多维维度中排序的数据，具有某种标题，最好放在表中，并使用div来管理页面上内容的布局。(另一种思考“表格数据”的方式是尝试以图表形式绘制它……如果你不能，它可能不是最好的表示在一个表中)

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.

在这两种情况下，“最后一英里”带宽的增加，以及更快的个人电脑缓解了这些因素，但它们仍然是许多网站存在的问题。

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.

我将一个接一个地看你的论点，并试着指出其中的错误。

将内容与布局分开是很好的 但这是一个错误的论点;陈词滥调的思考。

It's not fallacious at all because HTML was designed intentionally. Misuse of an element might not be completely out of question (after all, new idioms have developed in other languages, as well) but possible negative implications have to be counterbalanced. Additionally, even if there were no arguments against misusing the <table> element today, there might be tomorrow because of the way browser vendors apply special treatment to the element. After all, they know that “<table> elements are for tabular data only” and might use this fact to improve the rendering engine, in the process subtly changing how <table>s behave, and thus breaking cases where it was previously misused.

那又怎样?我的老板在乎吗?我的用户关心吗?

视情况而定。你的老板是尖头发吗?那他可能不在乎。如果她有能力，那么她就会在乎，因为用户会在乎。

也许我或我的开发伙伴谁必须维护一个网页关心…表是否更难维护?我认为使用表格比使用div和css更容易。

大多数专业的web开发人员似乎反对你[需要引用]。事实上，表的可维护性较差，这是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能会非常昂贵。另一方面，明智地将语义上有意义的HTML与CSS结合使用可能会将此类更改限制在CSS和所使用的图片上。

顺便说一下……为什么使用div或span可以很好地将内容与布局分开，而不是表格?只有div的良好布局通常需要大量嵌套的div。

深度嵌套<div>是反模式，就像表布局一样。优秀的网页设计师不需要太多这样的东西。另一方面，即使是这样深嵌套的div也没有很多表布局的问题。事实上，它们甚至可以通过逻辑地将内容划分为多个部分来构成语义结构。

代码的可读性 我觉得正好相反。大多数人懂html，很少人懂css。这是简单的。

“大多数人”不重要。专业人士。对于专业人士来说，表格布局比HTML + CSS带来更多的问题。这就像是说我不应该使用GVim或Emacs，因为记事本对大多数人来说更简单。或者我不应该使用LaTeX，因为MS Word对大多数人来说更简单。

SEO最好不要使用表格

我不知道这是不是真的，也不会把它作为一个论点，但它是合乎逻辑的。搜索引擎搜索相关数据。虽然表格数据当然可能是相关的，但它很少是用户搜索的内容。用户搜索页面标题或类似突出位置中使用的术语。因此，将表格内容排除在过滤之外，从而大幅减少处理时间(和成本!)是合乎逻辑的。

表比较慢。 必须插入一个额外的tbody元素。这对于现代网络浏览器来说是微不足道的。

额外的元素与表变慢无关。另一方面，表的布局算法要困难得多，浏览器通常必须等待整个表加载后才能开始布局内容。此外，缓存布局将不起作用(CSS可以很容易地缓存)。所有这些都在前面提到过。

向我展示一些使用表会显著降低页面速度的基准测试。

不幸的是，我没有任何基准测试数据。我自己也会感兴趣，因为这个论点确实缺乏一定的科学严谨性。

大多数需要升级的网站也需要新的内容(html)。一个新版本的网站只需要一个新的css文件的场景是不太可能的。

Not at all. I've worked on several cases where changing the design was simplified by a separation of content and design. It's often still necessary to change some HTML code but the changes will always be much more confined. Additionally, design changes must on occasion be made dynamically. Consider template engines such as the one used by the WordPress blogging system. Table layouts would literally kill this system. I've worked on a similar case for a commercial software. Being able to change the design without changing the HTML code was one of the business requirements.

Another thing. Table layout makes automated parsing of websites (screen scraping) much harder. This might sound trivial because, after all, who does it? I was surprised myself. Screen scraping can help a lot if the service in question doesn't offer a WebService alternative to access its data. I'm working in bioinformatics where this is a sad reality. Modern web techniques and WebServices have not reached most developers and often, screen scraping is the only way to automate the process of getting data. No wonder that many biologists still perform such tasks manually. For thousands of data sets.