为什么不在HTML中使用表格布局呢?

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

根据508法规(对于视障屏幕阅读器)，表格应该只用于保存数据，而不是用于布局，因为它会导致屏幕阅读器崩溃。至少别人是这么告诉我的。

如果您为每个div分配名称，您也可以使用CSS将它们一起蒙皮。只是让他们坐成你想要的样子有点麻烦。

无论如何，这并不是一个明确的论点，但是对于CSS，你可以使用相同的标记并根据介质改变布局，这是一个很好的优势。例如，对于打印页面，您可以安静地抑制导航，而不必创建打印机友好的页面。

我想使用表格元素进行布局确实与表格数据没有什么关系。那又怎样?我的老板在乎吗?我的用户关心吗?

谷歌和其他自动化系统做护理，它们在许多情况下同样重要。语义代码对于非智能系统来说更容易解析和处理。

# EYZ0

你忘记的一项是可访问性。例如，如果你需要使用屏幕阅读器，基于表格的布局就不能很好地转换。如果您使用政府，那么支持屏幕阅读器等可访问浏览器的可能是要求。

我也认为你低估了你在问题中提到的一些事情的影响。例如，如果您既是设计人员又是程序员，您可能没有充分了解它如何将表示和内容分开。但一旦你进入一个商店，他们是两个不同的角色，优势就开始变得清晰起来。

如果你知道你在做什么并且有好的工具，CSS在布局方面确实比表格有显著的优势。虽然每一件物品本身都不能证明放弃餐桌是合理的，但总的来说还是值得的。

我曾经处理过一个包含6层嵌套表的网站，这个网站是由一些应用程序生成的，并且生成了无效的HTML，事实上，我花了3个小时的时间来纠正它，因为一个小的改变。

这当然是边缘情况，但是基于表的设计是不可维护的。如果你使用css，你分离了样式，所以在修复HTML时，你不必担心破坏。

同样，用JavaScript试试这个方法。将单个表单元格从一个位置移动到另一个表中的另一个位置。执行起来相当复杂，div/span只需要复制粘贴即可。

“我的老板在乎吗?”

如果我是你的老板。你会在乎的。,)如果你珍视你的生命。

我想补充的是，基于div的布局更容易维护、发展和重构。只是在CSS中做了一些改变来重新排序元素，这就完成了。根据我的经验，重新设计使用表的布局是一场噩梦(如果有嵌套的表，则会更糟)。

从语义的角度来看，你的代码也有意义。

内容和布局之间的分离也使它更容易为您的网站生成打印机友好的布局或不同的皮肤(样式)，而不必创建不同的html文件。有些浏览器(如Firefox)甚至支持从视图菜单中选择样式表。

而且我确实认为保持无表格布局更容易。你不需要担心行span, colspan等等。您只需创建一些容器div并将内容放置在需要的位置。也就是说，我认为它也更可读(<div id="sidebar"> vs <tr><td>...</td><td>...<td>sidebar</td></tr>)。

这只是一个你必须学会的小“技巧”(一旦你掌握了这个技巧，我认为它会更容易，更有意义)。

另外，别忘了，表格在移动浏览器上的渲染效果并不好。当然，iPhone拥有强大的浏览器，但并不是每个人都有iPhone。对于现代浏览器来说，表呈现可能是花生，但对于移动浏览器来说，它却是一堆西瓜。

我个人发现很多人使用了太多的<div>标签，但适度的话，它可以非常干净且易于阅读。你提到人们阅读CSS比阅读表格更困难;就“代码”而言，这可能是真的;但是在读取内容方面(查看>源代码)，用样式表理解结构要比用表容易得多。

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

参见:过度使用ViewState

看起来你只是习惯了桌子，就是这样。 将布局放在表格中会限制你的布局。用CSS你可以移动位，看看http://csszengarden.com/ 不，布局通常不需要很多嵌套的div 没有表格的布局和适当的语义HTML更干净，因此更容易阅读。 为什么不理解CSS的人要尝试阅读它呢?如果有人认为自己是一个web开发人员，那么对CSS的良好掌握是必须的 SEO的好处来自于将最重要的内容放在页面上方的能力

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

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

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

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

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

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

CSS布局通常在可访问性方面要好得多，前提是内容以自然的顺序出现，并且没有样式表也有意义。不仅仅是屏幕阅读器难以适应基于表格的布局:它们也使移动浏览器更难正确呈现页面。

此外，使用基于div的布局，你可以很容易地用打印样式表做一些很酷的事情，比如从打印页面中排除页眉、页脚和导航——我认为这是不可能的，或者至少很难用基于表格的布局做到这一点。

如果你怀疑使用div比使用表格更容易将内容与布局分离，请看看CSS禅园上基于div的HTML，看看改变样式表如何彻底改变布局，并考虑如果HTML是基于表格的，是否可以实现相同的布局多样性……如果你正在做一个基于表格的布局，你不太可能使用CSS来控制单元格中的所有间距和填充(如果你是这样，你几乎肯定会发现使用浮动div等更容易)。如果不使用CSS来控制所有这些，并且由于表格指定了HTML中从左到右和从上到下的顺序，表格往往意味着你的布局在HTML中变得非常固定。

实际上，我认为完全改变一个基于div和css的设计而不改变div是非常困难的。然而，使用基于div和css的布局，就更容易调整不同块之间的间距以及它们的相对大小。

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

这是一个错误的论点，因为HTML表格是布局!内容是表中的数据，表示形式是表本身。这就是为什么从HTML中分离CSS有时会非常困难。您不是将内容与表示分开，而是将表示与表示分开!一堆嵌套的div和一个表没有什么不同——它只是一组不同的标签。

把HTML和CSS分开的另一个问题是，它们需要彼此的密切了解——你真的不能把它们完全分开。无论您做什么，HTML中的标记布局都与CSS文件紧密耦合。

我认为表与div的区别取决于应用程序的需要。

在我们在工作中开发的应用程序中，我们需要一个页面布局，其中各个块将动态地调整自己的大小以适应其内容。我花了几天时间试图让它与CSS和div跨浏览器工作，这是一个完全的噩梦。我们切换到表格，它只是工作。

然而，我们的产品有一个非常封闭的受众(我们销售的是带有web界面的硬件)，可访问性问题不是我们关心的问题。我不知道为什么屏幕阅读器不能很好地处理表格，但我猜如果这是开发人员必须处理的方式。

我没有对DIVs有利的论据。

我会说:如果事实属实，那就接受吧。

值得注意的是，要找到一种好的DIV+CSS方法来在两列或三列中呈现内容，并且在所有浏览器上都是一致的，并且看起来仍然是我想要的方式，即使不是不可能，也是很困难的。

在我的大多数布局中，这让平衡感向表格倾斜了一点，尽管我对使用它们感到内疚(不知道为什么，人们只是说它不好，所以我试着听他们的)，最后，务实的观点是，对我来说，使用表格更容易、更快。我不是按小时计酬的，所以桌子对我来说比较便宜。

这是我的程序员的回答从结果线程

语义101

首先看一下这段代码，想想哪里出了问题……

class car {
int wheels = 4;
string engine;
}


car mybike = new car();
mybike.wheels = 2;
mybike.engine = null;

当然，问题在于自行车不是汽车。car类对于bike实例是不合适的类。代码没有错误，但是在语义上不正确。这对程序员的形象很不利。

语义102

现在将此应用于文档标记。如果您的文档需要显示表格数据，那么适当的标记应该是<table>。但是，如果您将导航放在表中，那么您就误用了<table>元素的预期用途。在第二种情况下，您没有表示表格数据——您(错误地)使用<table>元素来实现表示目标。

结论

游客会注意到吗?不。你的老板在乎吗?也许吧。作为程序员，我们有时会偷工减料吗?当然。但是我们应该吗?不。如果使用语义标记，谁会受益?你，还有你的职业声誉。现在去做正确的事吧。

不幸的是，CSS Zen Garden不能再作为一个好的HTML/CSS设计的例子。实际上，他们最近的所有设计都使用图形作为部分标题。这些图形文件是在CSS中指定的。

因此，一个网站的目的是展示将设计排除在内容之外的优势，现在却经常犯将内容纳入设计的不可言说的罪。(如果HTML文件中的节标题要更改，则显示的节标题不会更改)。

这只能说明，即使是那些主张严格的DIV &CSS信仰宗教，不能遵循自己的规则。你可以用它来指导你如何严格遵守它们。

• 508符合性-屏幕阅读器能够理解你的标记。
• 等待呈现——直到到达</table>元素的末尾，表才会在浏览器中呈现。

div和CSS的定位允许一个更灵活的设计，导致更容易修改和模板的网页。

也就是说，如果你对灵活性不感兴趣，那么使用一个表而不是一些由CSS变形成表的div绝对是更容易和更快的。我倾向于在设计时使用表格，只是为了更快地让它看起来正确。

围绕语义标记的整个思想是标记和表示的分离，其中包括布局。

Div并没有取代表，它们在将内容分离为相关内容块(，)方面有自己的用途。当您不具备这些技能并且依赖于表格时，您通常必须将内容分离到单元格中以获得所需的布局，但是在使用语义标记时，您不需要触摸标记来实现表示。在生成标记而不是静态页面时，这一点非常重要。

开发人员需要停止提供暗示布局的标记，以便我们这些拥有显示内容技能的人能够继续工作，并且开发人员不必在表示需要更改时返回他们的代码进行更改。

使用表格布局的工具可能会因为创建布局所需的大量代码而变得异常沉重。SAP的Netweaver Portal默认使用TABLE来布局页面。

在我目前的工作中，生产SAP门户有一个主页，它的HTML超过60K，有7个表那么深，在页面中有3次。再加上Javascript，误用了16个iframe，其中有类似的表格问题，CSS过重等，页面重量超过5MB。

花点时间降低页面重量，这样你就可以利用带宽与用户进行互动，这是值得的。

我曾经了解到，一个表是立即加载的，换句话说，当连接很慢的时候，表所在的空间保持空白，直到整个表被加载，另一方面，一个div加载从上到下的速度与数据到达的速度一样快，不管它是否已经完成。

如果你在这方面支持表格角度，找一个有表格的网站，然后给自己买一个屏幕阅读器——关掉屏幕阅读器，关掉你的显示器。

然后尝试一个不错的语义正确的div布局网站。

你会发现其中的不同。

如果表格中的数据是表格而不是为了布局页面，那么表格并不是邪恶的。

有必要弄清楚CSS和div，以便在页面布局中，中央内容列在侧栏之前加载和呈现。但是，如果你正在努力使用浮动div来垂直对齐一个logo和一些赞助文本，那就使用这个表格，继续生活吧。禅宗花园宗教并没有带来多少价值。

将内容与表示分开的思想是对应用程序进行分区，以便不同类型的工作影响不同的代码块。这实际上是关于变更管理的。但是编码标准只能以表面的方式检查代码的当前状态。

应用程序的更改日志依赖于编码标准来“将内容与表示分开”，它将显示跨垂直竖井的并行更改模式。如果对“内容”的更改总是伴随着对“表示”的更改，那么分区的成功程度如何?

如果您真的想高效地划分代码，请使用Subversion并检查更改日志。然后使用最简单的编码技术——divs、表、JavaScript、include、函数、对象、延续等等——来构建应用程序，以便以简单和舒适的方式进行更改。

一张桌子来布置也不错。但大多数情况下，仅靠一张表是无法得到所需的布局的。很快你就有了2到3个嵌套表。这变得非常麻烦。

• 读起来要困难得多。这不能见仁见智。只是有更多嵌套的标签，上面没有识别标记。

• 将内容与表示分开是一件好事，因为它允许您专注于您正在做的事情。混合使用这两种方法会导致页面臃肿，难以阅读。

• 样式的CSS允许浏览器缓存文件，随后的请求会更快。这是巨大的。

• 表格将您锁定在设计中。当然，并不是每个人都需要CSS Zen Garden的灵活性，但我从来没有在一个网站上工作过，我不需要在这里和那里改变一点设计。用CSS就简单多了。

• 表格很难设计风格。你没有太多的灵活性(例如，你仍然需要添加HTML属性来完全控制一个表的样式)

我大概有4年没有用表格来处理非表格数据了。我没有回头。

我真的很想建议你读安迪·巴德的CSS掌握。棒极了。

Image at ecx.images-amazon.com http://ecx.images-amazon.com/images/I/41TH5NFKPEL._SL500_BO2,204,203,200_PIsitb-dp-500-arrow,TopRight,45，-64_OU01_AA240_SH20_.jpg

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

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

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

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

我想这事已经过去了。如果你看看行业的发展方向，你会发现CSS和开放标准是这场讨论的赢家。这反过来意味着对于大多数html工作，除了表单，设计师将使用div而不是表格。我很难做到这一点，因为我不是CSS专家，但事实就是这样。

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

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

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

当您需要确保元素在布局中保持特定的物理关系时，请使用表格。对于数据，表格通常是最适合使用的布局元素，因为您不希望列以超出预期的方式包装，从而混淆了关联。

也有人可能会说，必须保持特定关系的非数据元素也应该呈现在表中。

灵活的css布局非常适合于移动设备、大屏幕、打印和其他显示类型的内容，但有时，内容必须以非常特定的方式显示，如果这要求屏幕阅读器无法轻松访问它，那么它可能是非常合理的。

我发现即使有最好的计划，潜水也会在几个方面存在不足。例如。divs不可能有一个总是位于浏览器底部的底部栏，即使其余的内容没有到浏览器底部。此外，除了三个列之外，您不能优雅地做任何事情，并且您不能让列根据其内容的宽度增长和收缩。最后，我们尝试先使用div。然而，我们不会限制我们的html设计基于一些宗教内容vs理想的布局。

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

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

这一点也不荒谬，因为HTML是有意设计的。某种元素的误用可能并非完全没有问题(毕竟，其他语言中也出现了新的习语)，但可能产生的负面影响必须加以平衡。此外，即使今天没有反对滥用<table>元素的理由，但由于浏览器供应商对该元素应用特殊处理的方式，明天可能会出现这种情况。毕竟，他们知道“<table>元素仅用于表格数据”，并可能使用这一事实来改进渲染引擎，在此过程中微妙地改变<table>的行为，从而打破以前滥用它的情况。

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

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

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

# EYZ0 # EYZ1。表是实际上更难以维护应该是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能会很贵。另一方面，明智地使用语义上有意义的HTML，并结合css# EYZ4将这些更改限制在CSS和所使用的图片上。

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

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

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

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

SEO最好不要使用表格

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

表变慢。 必须插入一个额外的tbody元素。

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

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

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

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

一点也不。我曾经处理过几个通过分离内容和设计来简化设计更改的案例。更改一些HTML代码通常仍然是必要的，但这些更改总是受到更大的限制。此外，有时必须动态地进行设计更改。考虑模板引擎，例如WordPress博客系统所使用的模板引擎。表格布局会扼杀这个系统。我曾为一个商业软件处理过类似的案例。能够在不更改HTML代码的情况下更改设计是业务需求之一。

另一件事。表格布局使得网站的自动解析(屏幕抓取)更加困难。这可能听起来微不足道，因为谁会这么做呢?我自己也很惊讶。如果所讨论的服务没有提供WebService替代方案来访问其数据，那么屏幕抓取可以提供很大帮助。我在生物信息学工作，这是一个令人悲伤的现实。大多数开发人员还没有接触到现代web技术和WebServices，通常，屏幕抓取是使获取数据过程自动化的唯一方法。难怪许多生物学家仍然手动完成这些任务。成千上万的数据集。

作为纯布局使用的表格确实会带来一些可访问性问题(我听说过)。但我理解这里被问到的问题，你正在通过使用表格来确保页面上某些东西的正确对齐来破坏网络。

我以前听到有人说，FORM标签和输入实际上是数据，应该允许它们进入表。

使用一个表来确保一些元素正确排列会导致代码大量增加，这种说法往往包含了单个DIV如何满足所有需求的示例。他们不总是包括10行CSS和特殊的浏览器技巧，他们必须为IE5、IE5.5、IE6、IE7……

我认为这仍然是关于在你的设计中使用平衡。表格在工具箱里，记住它们是干什么用的……

我尽量避免使用TABLEs，但是当我们设计复杂的表单，混合了多种控件类型和不同的标题位置，并对分组进行了非常严格的控制时，使用DIVs是不可靠的，甚至几乎是不可能的。

现在，我不会说这些表单不能重新设计以更好地适应基于DIV的布局，但是对于其中的一些表单，我们的客户坚决不改变以前版本(用经典ASP编写的)的现有布局，因为它与用户熟悉的纸质表单相似。

因为表单的表示是动态的(其中某些部分的显示是基于案例的状态或用户的权限)，所以我们使用一组堆叠的div，每个div包含一个由逻辑分组的表单元素组成的TABLE。TABLE的每一列都被分类，这样CSS就可以控制它们。这样，我们就可以关闭表单的不同部分，而不会出现在div中不是表来换行的问题。

根据过去的经验，我必须选择DIV。即使在OOP中，主要目的也是减少对象之间的耦合，因此这个概念可以应用于DIVS和表。表用于保存数据，而不是围绕页面排列数据。DIV是专门设计用于在页面周围排列项目的，因此设计应该使用DIV，表应该用于存储数据。

此外，编辑由表格组成的网站是非常困难的(在我看来)

这并不是关于“div在布局上是否比表格更好”。理解CSS的人可以非常直接地使用“布局表”复制任何设计。真正的胜利是使用HTML元素来实现它们的目的。不将表用于非表数据的原因与不将整数存储为字符串的原因相同——当您按照设计的目的使用技术时，技术工作起来要容易得多。如果曾经有必要使用表格进行布局(因为20世纪90年代早期浏览器的缺陷)，那么现在肯定没有了。

当然，这篇文章有点小题大做，争论似乎很简单，很容易反驳。

网页是Web开发人员的领域，如果他们说div &CSS比表格更好，这对我来说已经足够好了。

如果布局是由服务器应用程序生成的表实现的，那么新的布局意味着对应用程序的更改，应用程序的重新构建和重新部署，而不仅仅是对css文件的更改。

另外,可访问性。用于布局的表格会使网站无法访问，所以不要使用它们。这是显而易见的，更不用说违法了。

我认为没有人会在意一个网站是如何设计/实现的，当它运行得很好并且运行得很快的时候。

我在HTML标记中同时使用“table”和“div”/“span”标记。

让我给你一些我为什么选择跳水的理由:

1. 对于一个表，你必须写至少3个标签(table, tr, td, thead, tbody)，为了一个好的设计，有时你有很多嵌套的表

2. 我喜欢在页面上有组件。我不知道该怎么解释，但我会尽力的。假设你需要一个标志，这必须被放置，只是它的一小部分，在下一页的内容。使用表格，你必须切割2张图像，并将其放入2个不同的td。使用DIVs，你可以有一个简单的CSS来安排它作为你想要的。你最喜欢哪种解决方案?

3. 当超过3个嵌套表做的事情，我正在考虑重新设计它使用DIVs

但是我仍然在使用表格:

1. 表格数据

2. 扩展自我的内容

3. 快速解决方案(原型)，因为DIVs盒子模型在每个浏览器上是不同的，因为许多生成器使用表格等

使用DIV，您可以轻松地进行切换。例如，你可以这样做:

Menu | Content


Content | Menu


Menu
----
Content

在CSS中更改它很容易，而在HTML中则不然。你也可以提供几种风格(右手，左手，专为小屏幕)。

在CSS中，您还可以将菜单隐藏在用于打印的特殊样式表中。

另一个好处是，你的内容在代码中总是按照相同的顺序(菜单在前，内容在后)，即使在视觉上它是以其他方式呈现的。

表不是在一般情况下比CSS更容易或更易于维护。然而，对于一些具体的布局问题，表确实是最简单和最灵活的解决方案。

在表示标记和CSS支持相同类型的设计的情况下，CSS显然是更可取的，没有人会认为font-tags比在CSS中指定排版更好，因为CSS提供了与font-tags相同的功能，但以一种更干净的方式。

然而，表的问题基本上是CSS中的表布局模型在Microsoft Internet Explorer中不受支持。因此，表和CSS在功能上是不等效的。缺少的部分是表的网状的行为，其中单元格的边缘垂直和水平对齐，而单元格仍然展开以包含它们的内容。如果不硬编码一些维度，这种行为在纯CSS中是不容易实现的，这使得设计变得僵硬和脆弱(只要我们必须支持Internet Explorer -在其他浏览器中，这很容易通过使用display:table-cell来实现)。

因此，这并不是一个表或CSS更可取的问题，而是一个认识到使用表可以使布局更灵活的具体情况的问题。

不使用表的最重要原因是可访问性。Web内容可访问性指南http://www.w3.org/TR/WCAG10/建议不要使用表格进行布局。如果您担心可访问性(在某些情况下，您可能有法律义务这样做)，即使表更简单，也应该使用CSS。注意，您可以使用总是创建与表相同的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>

我在基于表格的布局中看到的唯一干净的地方是我对缩进的过度热情。我确信内容部分将有另外两个嵌入式表。

另一件需要考虑的事情:文件大小。我发现基于表格的布局通常是CSS布局的两倍大。在我们的高速宽带上，这不是一个大问题，但在那些拨号调制解调器上。

所见即所得!我不能让我们的设计师停止使用嵌套的DIVS和由elementID css样式的模板，这些模板应该由客户端在CMS项目中使用。这就是所见即所得在线编辑器的全部意义所在。你同时控制内容和布局!在这个场景中，根本就没有分离。在一些外部样式表中定位和设置样式的div对于所见即所得编辑的整个思想来说是一种诅咒。可以看到表、插入的行、组合的单元格等等。祝你好运，以一种不会让用户感到沮丧的方式尝试这种divs。

超级简单的回答:用表格设计可维护的网站是很困难的，而用标准的方法来做是很简单的。

网站不是一个表格，它是相互交互的组件的集合。把它描述成一个表是没有意义的。

一个例子:你想要居中 一个页面的主要内容区域，但在 为了把浮体装在里面， 它需要浮动。没有

这并不是在居中元素中“包含浮点数”的唯一方法。所以，这根本不是一个好的论点!

在某种程度上，“divs vs table”是一个错误的前提。

把一页快速地分成三列?说实话，表格是更简单。但是没有专业人士将它们用于布局，因为它们将页面元素的位置锁定在页面中。

真正的争论是“由CSS完成的定位(最好是在远程文件中)”，而不是“在页面中由HTML完成的定位”。相对于后者，每个人都能看到前者的好处吗?

1. 大小——如果你的页面布局是在HTML中，在页面中，它不能被缓存，它必须在每个页面上重复。如果你的布局是在一个缓存的CSS文件中，而不是在页面中，你将节省大量的带宽。
2. 多个开发人员可以同时在同一个页面上工作——我在HTML上工作，其他人在CSS上工作。不需要存储库，不存在覆盖、文件锁定等问题。
3. 做出改变更容易——在不同的浏览器中布局会有问题，但你只需要修复一个文件，即CSS文件，就可以把它们整理出来。
4. 可访问性，就像之前提到的。表格假设二维布局适合所有人。这不是一些用户如何看待你的内容，这不是谷歌如何看待你的内容。

考虑一下:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

表示包含6个单元格的表中的两行。能看到二维表格布局的人会在每张图片下看到标题。但是使用语音合成，或者PDA，以及搜索引擎蜘蛛，那是

picture picture picture caption caption caption

有了表格，这种关系就明显消失了。

div和CSS更适合完成简单地在HTML页面上布局矩形，以在最短的时间内实现给定的设计?的任务吗?不，它们可能不是。但我不是在快速布局矩形来实现给定的设计。我想的是更大的前景。

当我使用CSS设计我的布局时，我通常给每个主要部分都有自己的根(主体级别)div，并使用相对/绝对定位将其置于适当的位置。这比表更灵活一些，因为我不局限于可以用行和列表示的排列。

此外，如果我决定我想要重新安排布局(说我想要导航栏现在在右边)，我可以简单地去改变一个地方(CSS文件)的元素位置，HTML不需要改变。如果我对表执行此操作，我将不得不进入并找到信息，并进行大量属性修改和复制粘贴以获得相同的效果。

事实上，使用CSS，我甚至可以让我的用户选择他们想要的布局如何工作。只要内容区域的一般大小不改变，我完全可以使用一些PHP脚本来根据用户的偏好输出CSS，并允许他们根据自己的喜好重新排列站点。同样，对于表也是可以的，但是维护起来要困难得多。

最后，CSS提供了一个表永远无法提供的主要好处:基于显示设备重新格式化内容的能力。CSS允许我在打印机上使用与显示器上完全不同的样式集(包括位置、格式等)。这也可以扩展到其他媒体，一个很好的例子是Opera Show，它允许一个设计巧妙(非常标准)的CSS增强页面被视为幻灯片显示。

因此，最终，灵活性和管理才是真正的赢家。一般来说，CSS允许你对布局做更多的事情。关于基于表的布局，没有从技术上讲不标准的地方，但是为什么要限制自己呢?

在过去，屏幕阅读器和其他可访问性软件很难以有效的方式处理表格。在某种程度上，这在屏幕阅读器中通过在“表格”模式和“布局”模式之间切换来处理，该模式基于它在表格中看到的内容。这通常是错误的，因此用户在浏览表时必须手动切换模式。在任何情况下，使用屏幕阅读器浏览大的、经常高度嵌套的表在很大程度上仍然非常困难。

当div或其他块级元素用于重新创建表并具有高度嵌套时也是如此。div的目的是用作一个形成和布局元素，因此，用于保存类似的信息，并将其布局在屏幕上供可视用户使用。当屏幕阅读器遇到一个页面时，它通常会忽略任何布局信息，包括基于CSS的，以及基于html属性的(并非所有屏幕阅读器都是如此，但对于最流行的屏幕阅读器，如JAWS、Windows Eyes和Linux的Orca是如此)。

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

最后，使用基于表的布局，为了实现对页面上元素位置的细粒度控制，经常使用高度嵌套的表。这有两个影响:1)增加每个页面的代码大小——由于导航和公共结构通常是用表格完成的，因此对于每个请求，相同的代码都是通过网络发送的，而基于div/css的布局只会将css文件拉过来一次，然后使用更少的啰嗦的div。2)。高度嵌套的表需要客户端的浏览器呈现更长的时间，导致加载时间稍慢。

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

考虑到所有这些，正如其他人所说，表格更容易，因为它们更面向网格，允许更少的思考。如果所讨论的站点预计不会存在很长时间，或者不会被维护，那么做最简单的事情可能是有意义的，因为它可能是最具成本效益的。然而，如果预期的用户群可能包括很大一部分残疾人，或者如果网站将由其他人长期维护，那么花时间以一种简洁、易访问的方式来做事情，最终可能会获得更多的回报。

我不得不用这两种方式来做网站，再加上第三种，可怕的“混合”布局，包括表格、div和样式:div /CSS轻松胜出。

为了匹配一个表格单元格的代码权重，您必须立即嵌套三个深度的div。这种效果会随着嵌套表的增加而扩大。

我也更喜欢做一个布局变化，而不是一个变化，在我的网站的每一页。

我可以完全控制divs/css的各个方面。表格以一种可怕的方式把它搞得一团糟，尤其是在IE浏览器中，我从来没有选择不支持这个浏览器。

我维护或重新设计一个div /css网站的时间只是表格的一小部分。

最后，我可以用CSS和几乎任何脚本语言创新多种可切换的布局。这对我来说是不可能的。

在你做决定的时候，祝你的投资回报率好运。

在维护内容的同时进行网站维护和设计检修(这一直都在发生，尤其是在电子商务中):

内容和设计通过表格混合在一起=更新内容和设计。

内容与设计分离=更新设计和少量内容。

如果我有自己的方式，我会将内容保存在PHP中，生成XML，转换为XSLT中的标记，并使用CSS和Javascript进行交互设计。对于Java方面的东西，JSP到JSTL来生成标记。

这并不一定是一场战争。和谐是可能的。

使用一个表的整体布局和div在其中。

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

看，没有嵌套表。

我读过很多关于如何用divs实现这一点的文章，但从来没有发现任何事情，每次都没有问题。

一旦你有了整体结构，Divs是很棒的，但坦率地说，流体页眉/页脚和三个流体列是Divs的一大痛苦。Divs不是为流动性而设计的，所以为什么要使用它们呢?

注意，这种方法将在链接文本为您提供100%的CSS遵从性

1:是的，你的用户很关心。如果他们使用屏幕阅读器，它就会丢失。如果我使用任何其他试图从页面中提取信息的工具，遇到不用于表示表格数据的表是一种误导。

使用div或span分隔内容是可以接受的，因为这正是这些元素的含义。当我，一个搜索引擎，一个屏幕阅读器或其他任何东西，遇到一个表格元素，我们期望这意味着“以下是表格数据，表示在一个表中”。当我们遇到div时，我们期望“这是一个用于divide我的内容到单独的部分或区域的元素。

2:可读性:错误。如果所有的表示代码都是css，我可以阅读html，我将理解页面的内容。或者我可以阅读css和理解的表示。如果html中的所有内容都是混杂在一起的，那么在我甚至可以看到什么是内容，什么不是内容之前，我必须在脑海中剔除所有与表示相关的部分。 此外，我害怕遇到一个不懂css的web开发人员，所以我真的不认为这是一个问题

3:表比较慢:是的，它们比较慢。原因很简单:必须完全解析表，包括它们的内容，然后才能呈现它们。当遇到div时，可以渲染它，即使是之前，它的内容也已经被解析了。这意味着div会在页面加载完成之前显示出来。

还有一个好处是，表格更加脆弱，在不同的浏览器中呈现的效果并不总是一样的，不同的字体和字体大小以及所有其他可能导致布局变化的因素。表格是一种很好的方法，可以确保你的网站在某些浏览器中会偏离一两个像素，当用户改变字体大小或以任何其他方式改变设置时，它不会很好地缩放。

当然，第一条才是最重要的。许多工具和应用程序依赖于网页的语义。通常的例子是为视障用户设计的屏幕阅读器。如果你是一个网页开发人员，你会发现许多大公司可能会雇用你在一个网站上工作，即使在这种情况下，网站也是可访问的。这意味着你必须考虑html的语义。有了语义网，或者更相关的微格式、rss阅读器和其他工具，您的页面内容不再只能通过浏览器查看。

我很抱歉我的英语不好，但还有一个原因:

我在一些政府机构工作，不使用TABLE的首要原因是残疾人。他们使用机器“翻译”网页。

问题是这个“翻译机器”不能阅读网站，如果它是由TABLE。为什么?因为TABLE是用于数据的。

事实上，如果你使用TABLES，你必须为每个cell指定一些信息，让残疾人知道他们在TABLE中的位置。想象一下，你有一个大表格，必须放大才能看到屏幕上的一个单元格:你必须知道你在哪一行/col。

因此，使用DIV，并且禁用可以简单地阅读文本，并且不会得到一些关于行/cols的奇怪信息，当它们不需要在那里时。

我也更喜欢TABLE来制作快速简单的模板，但我现在习惯了CSS…它很强大，但你真的必须知道你在做什么……：）

几年前，我研究了屏幕阅读器和表格的问题，得出了与大多数开发者想法相矛盾的信息:

# EYZ0 < / >

你可能会听到一些易访问性倡导者说布局表是一个坏主意，应该使用CSS布局技术。他们说的有道理，但是，老实说，在可访问性方面，使用表格进行布局并不是最糟糕的事情。只要桌子在设计时考虑到可访问性，各种残疾的人都可以轻松地使用桌子。”

数据:使用表格。布局:使用样式。使用非常精简的浏览器(即链接 2或猞猁，没有样式，只有简单的标记)可以最快地呈现表。

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

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

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

谷歌对表中包含的文本内容给予非常低的优先级。我在给当地一家慈善机构提供搜索引擎优化建议。在检查他们的网站时，他们使用表格来布局网站。查看每一页，无论我在谷歌搜索框中使用了什么单词或单词组合，这些页面都不会出现在任何搜索页面的顶部。(但是，通过在搜索中指定站点，页面将被返回。) 有一页按照正常标准写得很好，可以在搜索中产生良好的结果，但它仍然没有出现在任何返回的搜索结果的前几页中。(请注意，这篇文章是在一个表格中。) 然后，我在页面上发现了一段文本，这是一个div而不是一个表格。我们在搜索引擎中放入一些来自该div的单词。 结果呢?它在搜索结果中排名第二。

1. 尝试合并/分割一个10/20的深度colspan/rowspan。不止一次，我不得不抑制自己想和别人打架的本能。(? !］
2. 尝试在不改变可见顺序的情况下改变源代码顺序。[SEO，可用性，…]
3. 我们正在查看的非常(非常简单)的页面是~150K。我打赌它几乎可以减半使用适当的CSS。[SEO(是的，SEO，阅读最新的谷歌规格等)，perfo，…]
4. 尝试创建一个可以在任何宽度下工作的迭代器模板。
5. 在这个基于表格的SO介质中讨论这个问题可以制造奇点，毁灭我们所有人

CSS/DIV -这只是设计男孩的工作，不是吗?我花了数百个小时调试DIV/CSS问题，在互联网上搜索一些标记，让我在一个不知名的浏览器上工作——这让我发疯。你做一个小小的改变，整个布局就会变得非常糟糕——这其中的逻辑在哪里呢?花几个小时把一个东西往这边移动3个像素，另一个东西往那边移动2个像素，让它们都对齐。在我看来，这是完全错误的。仅仅因为你是一个纯粹主义者，有些事情“不应该做”并不意味着你应该在任何情况下充分利用它，尤其是当它让你的生活变得简单1000倍的时候。

因此，我最终决定，纯粹出于商业考虑，尽管我保持使用最少，但如果我预计要工作20个小时才能正确放置一个DIV，我将坚持使用一个表。这是错误的，它让纯粹主义者感到不安，但在大多数情况下，它花费的时间更少，管理成本更低。然后，我可以集中精力使应用程序按照客户的要求工作，而不是取悦纯粹主义者。毕竟，他们确实在支付账单，我对一个强制使用CSS/DIV的经理的争论——我只是想指出，客户也在支付他的工资!

所有这些CSS/DIV争论出现的唯一原因是因为CSS的缺点，首先是因为浏览器之间不兼容，如果它们相互兼容，世界上一半的网页设计师将失业。

当你设计一个窗口表单的时候你不会在你把控件放好之后去移动它们所以我觉得这对我来说有点奇怪为什么你想在一个网页表单上这么做。我实在无法理解这种逻辑。从正确的布局入手，找出问题所在。我认为这是因为设计人员喜欢玩弄创造力，而应用程序开发人员更关心的是让应用程序实际工作，创建业务对象，实现业务规则，解决客户数据之间的关系，确保事物满足客户的需求-你知道-就像现实世界的东西一样。

不要误解我的意思，这两种观点都是正确的，但是请不要因为开发人员选择了一种更简单、更合乎逻辑的方式来设计表单而批评他们。我们常常有比正确使用表而不是div的语义更重要的事情要担心。

在这个讨论的基础上，我将一些现有的tds和trs转换为div。花了45分钟把它弄得乱七八糟想把所有东西都排列整齐然后我就放弃了。td在10秒后回来-工作-立即-在所有浏览器上，没有更多的事情要做。请试着让我明白——你有什么理由让我用其他方式做这件事!

因为维护一个使用表格的网站是非常困难的，并且需要更长的编码时间。如果你害怕漂浮的潜水器，那就去上一门潜水课吧。它们并不难理解，而且它们的效率大约是前者的100倍，麻烦也少了100万倍(除非你不理解它们——但是，嘿，欢迎来到计算机的世界)。

任何考虑用表格做布局的人最好不要指望我来维护它。这是渲染网站最落后的方式。感谢上帝，我们现在有了更好的选择。我永远不会回去。

有些人可能没有意识到使用现代工具创建一个网站所带来的时间和精力的好处，这很可怕。

布局应该简单。事实上，有文章讲述了如何在CSS中实现带有页眉和页脚的动态三列布局，这表明它是一个糟糕的布局系统。当然，你可以让它工作，但网上有数百篇关于如何做的文章。对于类似的表格布局，几乎没有这样的文章，因为这是显而易见的。无论你说什么反对表格和支持CSS，这一事实都推翻了这一切:CSS中基本的三列布局通常被称为“圣杯”。

如果这不能让你说“WTF”，那么你现在真的需要放下酷爱饮料了。

我喜欢CSS。它提供了惊人的样式选项和一些很酷的定位工具，但作为一个布局引擎，它是有缺陷的。需要某种类型的动态网格定位系统。一个直接的方法来对齐多个轴上的盒子，而不知道他们的大小。我才不管你管它叫什么桌子或& lt; gridlayout>等等，但这是CSS所缺少的基本布局特性。

更大的问题是，由于不承认有缺失的特性，CSS狂热者一直在阻碍CSS的发展。如果CSS能像世界上其他布局引擎一样提供像样的多轴网格定位，我很乐意停止使用表格。(你应该意识到这个问题已经被除了W3C之外的所有人用多种语言解决过很多次了，对吧?没有人否认这样一个功能是有用的。)

叹息。足够的通风。去吧，把头埋进沙子里。

Flex有一个标签，用于在垂直列中布局内容。说实话，我不认为他们在布局/内容方面做得很好，但至少他们已经解决了这个问题。

像许多对CSS感到沮丧的人一样，我也到处寻找一个简单的答案，当我以为我找到了它时，我感到兴奋，然后当我在Chrome中打开页面时，我的希望破灭了。我肯定没有足够的技能说这是不可能的，但我还没有看到任何人提供样本代码供同行评审，明确地证明它可以可靠地完成。

那么，这个岛的CSS方面有人能推荐一种布局垂直列的心态/方法吗?我尝试过在第二行和第三行绝对定位，但我最终与到处重叠的东西和浮动有类似的问题，如果页面缩小。

如果有答案，我会欣喜若狂，只要告诉我，“嘿，你试过**流:垂直|水平”，我就完全不受你的困扰了。

DOM操作在基于表的布局中是很困难的。

使用语义div:

$('#myawesomediv').click(function(){
// Do awesome stuff
});

表:

$('table tr td table tr td table tr td.......').click(function(){
// Cry self to sleep at night
});

当然，第二个例子有点愚蠢，您总是可以将id或类应用到表或td元素上，但这将增加语义值，这是表的支持者强烈反对的。

我很惊讶地发现有些问题还没有涉及到，所以除了之前提出的所有非常有效的观点之外，以下是我的2点看法:

1。。# EYZ0

a) CSS过去对SEO有非常重要的影响，它允许在页面中放置你想要的内容。几年前，搜索引擎非常重视“页面上”的因素。页面顶部的内容被认为比底部的内容更与页面相关。对于蜘蛛来说，“页面顶部”意味着“代码的开头”。使用CSS，您可以在代码的开头组织富含关键字的内容，并且仍然可以将其放置在页面中您喜欢的任何位置。这仍然是一些相关的，但在页面上的因素是越来越不重要的页面排名。

b)当布局转移到CSS时，HTML页面更轻，因此对于搜索引擎蜘蛛加载更快。(蜘蛛不需要下载外部CSS文件)。快速加载页面是一个重要的排名考虑几个搜索引擎，包括谷歌

c) SEO工作通常需要测试和更改内容，这与基于CSS的布局更方便

。2。# EYZ0

用编程方式生成表要比等效的CSS布局容易得多。

foreach ($comment as $key=>$value)
{
echo "<tr><td>$key</td><td>$value</td></tr>";
}

生成表很简单，也很安全。它是自包含的，可以很好地集成到任何模板中。用CSS做同样的事情要困难得多，而且可能根本没有任何好处:很难在飞行中编辑CSS样式表，并且内联添加样式与使用表没有什么不同(内容没有与布局分离)。

此外，在生成表时，内容(在变量中)已经与布局(在代码中)分离，使其易于修改。

这就是为什么一些设计非常好的网站(例如SO)仍然使用表格布局的原因之一。

当然，如果需要通过JavaScript对结果进行操作，那么div是值得的。

。3。# EYZ0

在找出适合特定受众的方法时，能够以各种方式更改布局以找出最佳结果是很有用的。基于CSS的布局使事情变得相当简单

。4。# EYZ0

布局表通常被鄙视，因为“每个人都知道div &CSS”才是正确的选择。

然而，事实仍然是，表创建更快，更容易理解，比大多数CSS布局更健壮。(是的，CSS可以很健壮，但是在不同的浏览器和屏幕分辨率上快速浏览一下网络就会发现情况并非如此)

桌子有很多缺点，包括维护、缺乏灵活性……但是我们不要把孩子和洗澡水一起丢了。快速可靠的解决方案有很多专业用途。

前段时间，我不得不用表格重写了一个干净简单的CSS布局，因为相当一部分用户会使用对CSS支持非常差的旧版本IE

就我而言，我已经厌倦了“哦，不!”布局的表格!”

至于那些“它不是为了这个目的而设计的，因此你不应该这样使用它”的人群，这不是虚伪吗?你怎么看待所有的CSS技巧，你必须使用使该死的东西工作在大多数浏览器?他们是为了这个目的吗?

根据我对表的了解，如果嵌套了太多的表，在呈现页面时浏览器会有很大的开销。

1 -浏览器必须等待呈现最终视图，直到整个表被加载。

2 -渲染表的算法是昂贵的，并且不是一次性的。当浏览器获得内容时，将尝试计算内容的宽度和高度来呈现。所以，如果你有嵌套的表格，比如说，浏览器已经收到了第一行，第一个单元格有大量的内容，宽度和高度没有定义，它会计算宽度，并渲染第一行， 在同一时间，当它得到第二行将单元格#2有负载的内容!现在它将计算第二行单元格的宽度。第一个呢?它将递归地计算宽度。这对客户端来说很糟糕。 (举个例子)作为一个程序员，你会优化一些东西，比如获取数据的时间，优化数据结构等等。你优化的东西在服务器端完成，比如在2秒内，但最终用户在8秒内得到最终视图。这里出了什么问题? 1. 可能是网络慢了吧!如果网络没有问题呢?网络在接下来的1秒内传递的内容是什么?这额外的5秒在哪里被消耗掉了?需要担心的事情——浏览器可能会花费大量时间来估计和呈现表!< / p > 如何优化表? 如果你使用表格，我建议，总是定义单元格的宽度。这并不能保证浏览器会盲目地只取这个宽度，但是会对浏览器决定初始宽度有很大的帮助

但是，最后，div是CSS可以被浏览器缓存的好方法;而表没有缓存!

通过仍然使用表格布局，我们错过了在div方面的创新。

在架构和表格布局工具方面，我还没有看到太多创新。

我想说，撇开所有的理论，实际上布局与CSS和div更快。相反，在这个方向上的创新使它变得更容易。

在我看来，严格分离表示和内容的问题大致类似于c++中头文件与实现文件的分离。这是有道理的，但也可能是一种痛苦。在Java和c#中，类是在一个源文件中定义的。这些新语言的作者注意到了一些让程序员头疼的问题，他们把它解决了。这似乎是这次讨论的要点。一方说CSS太难了，另一方说必须成为CSS大师。

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

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