我相信这是一个与普遍问题有关的问题。HTML诞生时，没有人能预见到它的广泛应用。另一项在自身成功的重压下几乎崩溃的技术。当HTML页面用vi在绿色文本终端上编写时，向页面访问者显示数据所需要的只是一个TABLE，而且大多数数据都是以表格形式显示的。

我们都知道事物是如何进化的。相对来说，table最近已经过时了，但是有很多理由更喜欢基于div和CSS的布局(可访问性不是最后一个)。当然我不能写一个CSS来拯救我的生命:-)，我认为图形设计专家应该总是在手边。

也就是说……即使在现代网站中，也有许多数据应该在表格中显示。

事实上，这是一个激烈争论的问题，这证明了W3C未能预见到将尝试的布局设计的多样性。使用divs+css进行语义友好的布局是一个很好的概念，但实现的细节有很大的缺陷，实际上限制了创作的自由。

我曾试图将我们公司的一个网站从餐桌切换到餐桌，这让我非常头疼，以至于我完全放弃了投入其中的工作时间，回到餐桌上。为了获得垂直对齐的控制，我试图与我的跳水手搏斗，这让我受到了重大的心理问题的诅咒，只要这场辩论继续下去，我就永远不会动摇。

人们必须经常想出复杂而丑陋的变通办法来实现简单的设计目标(比如垂直对齐)，这一事实强烈地表明这些规则还不够灵活。如果规格已经足够了，那么为什么高调的网站(如SO)发现有必要使用表格和其他变通方法来改变规则呢?

布局的灵活性 想象一下，您正在创建一个带有大量缩略图的页面。 div: 如果你把每个缩略图放在DIV中，向左浮动，可能一行有10个缩略图。让窗口变窄，BAM -它是一行6个，或者2个，或者其他合适的。 表: 你必须明确地说一行中有多少单元格。如果窗口太窄，用户必须水平滚动。

可维护性 和上面的情况一样。现在要向第三行添加三个缩略图。 div: 把它们加进去。布局会自动调整。 表: 将新单元格粘贴到第三行。哦!现在那里的商品太多了。从那一行切一些，放在第四行。现在那里的商品太多了。从那一行切一些……(等) (当然，如果您使用服务器端脚本生成行和单元格，这可能不是问题。)

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.

对于简单的布局问题，为什么不改变表示必须完全独立的规则呢?一个新的标签(或者一些div标签的扩展)可以让我们直接在HTML中控制显示?毕竟，我们不是已经将表示泄露到HTML中了吗?看看h1, h2, h6。我们都知道这些控制表示。

阅读代码(HTML就是代码)的能力非常重要。专家们往往忽略了使编程环境尽可能为大众所接受的重要性。认为只有专业程序员才重要是非常短视的。

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

为了回应“表格更慢”的论点——你考虑的是渲染时间，这是一个错误的度量。通常情况下，开发人员会编写一个巨大的表格来完成页面的整个布局——这大大增加了要下载的页面的大小。不管你喜不喜欢，仍然有大量的拨号用户。

参见:过度使用ViewState