为什么要使用表格来构建布局？答案

【问题标题】：Why use tables to structure your layout?为什么要使用表格来构建布局？
【发布时间】：2010-09-30 09:18:18
【问题描述】：

查看 Stack Overflow 的源代码，我注意到他们使用了很多表格和内联 CSS，我发现奇怪的是使用内联表格属性格式。

<table width="100%">

我只是好奇他们为什么使用表格而不是流行的（或曾经流行的）DIV 来构建他们的模板是否有任何具体原因。

同样...使用 CSS 的目的包括在同一页面上使用内联 CSS（我知道这可能有一个很好的答案/解决方案...我只是好奇它们是什么)

我知道将表格用于表格数据并没有什么问题……但在这种情况下，Stack Overflows 表格用于结构。

【问题讨论】：

这里有一个想法：为什么不自己做呢？这里有足够多的人认为它可以完成（包括我自己），那么为什么不创建一个新问题（当然是社区 Wiki）并让用户有机会修复它？
这也是非常正确的！...我想我可能会尝试一下...。不过我知道，无论我做什么...我都会被一些 css 咀嚼/div 忍者。

标签： html css html-table

【解决方案1】：

Tables vs. Divs 是一场毫无意义的圣战。

以特定方式使用表格进行布局存在特定问题，可能会导致问题。其中之一是在单个表格中构建整个站点布局，以处理边距和位置 - 由于表格的呈现方式，这经常意味着网站不会在内容下载时由浏览器引擎逐步呈现，并且只能在收到整个东西后渲染。对于大页面或慢速调制解调器用户，他们可能会长时间盯着空白页面，这是“坏事”。不要介意在 mozilla/ie5 一代浏览器中表格呈现的许多不一致，这使得一致的跨浏览器表格布局有些痛苦，尤其是单元格中的图像。

纯 div 路径的支持者喜欢谈论内容与表示，因为理论上 HTML 4.01 是纯内容，所有这些都是有意义的。 div 提供了抽象意义上的有意义的组织结构，然后由 CSS 独家呈现。在这些参数中，表仅在用于包含实际表格数据时才有效。当然，这忽略了这样一个事实，即对于任何足够复杂的布局，几乎总是有相当多的空 div 漂浮在周围，只是为了支持呈现 CSS 的必要钩子，打破了这种抽象的第一层。一旦这种抽象被破坏，就没有法律规定，当您的布局只需要 HTML 中没有有意义的内容的表示挂钩时，div 在某种程度上比 table 更合适。如果为了使布局正常工作，您不得不选择无意义的 div 或无意义的表格，请选择更容易的一个。

最后，要了解所有方法的局限性并使用最合适的方法。在许多情况下，使用表格比设置无意义（即无内容意义）的 div 数组更容易，并且表格呈现限制不适用。如果表格很小并且代表内部内容的一小部分，则渲染延迟无关紧要。

【讨论】：

大约 2 年前，我停止使用表格进行结构布局，而且我从未添加过空元素来帮助结构布局。添加 div 和 span 以获得结构帮助是非常好的，但它们仍应包含内容。
更正，因为我停止使用表格进行结构布局，所以我从来没有添加过空元素...
我真的同意你对这个问题的务实态度。要真正利用 CSS 确实需要以您描述的方式使用 div 和跨度...看看 CSS Zen Garden 以了解将 CSS 钩子留在 HTML 中的邪恶示例......
你可能没有添加一个空元素，但你已经添加了很多浏览器特定的黑客或 javascript 更正代码——这两者都很糟糕。或者您只创建简单的页面。
部分正确。我已经通过添加 hacks 完成了学习过程，但是一旦你习惯了它，你的 HTML/css 越干净，就越容易让它看起来和行为符合你的需要。我的前提是，如果它不起作用，您可能需要删除一些东西而不是添加一些东西。

【解决方案2】：

没有参与过SO开发，我只是泛泛而谈：

我发现tables 在浏览器中通常比基于CSS 的布局更容易且更一致。

此外，在尝试完成任务时经常会在这里和那里发出随机的CSS。我想它可以在以后重构。

关于他们为什么选择在 HTML 而不是 CSS 中设置表格的宽度，我不能说。

我知道 SO 在开始时使用了一位真实、诚实的设计师。不过，我不知道该设计师是否给了他们网站外观或实际标记的图像。

请不要因为我这样说而激怒我。我们不都是 CSS 忍者。

【讨论】：

是的，但是为什么表格上的宽度属性而不是宽度为 100% 的 CSS 类？
因为，可悲的是，他们做不同的事情。
究竟是什么？....我很想看看 Atwood 或 Spolsky 对此有何看法....我相信这是有充分理由的
致电并将其作为播客的问题。
希望如此，但如果它像“它有效”那么简单，我不会感到惊讶。他们似乎是务实的人。

【解决方案3】：

SO 可能是由程序员编写的，而不是 Web 开发人员。

【讨论】：

小心……他们在战斗的话。 ;)
我对 Web 开发人员没有任何意见。编程和 Web 开发都有自己的位置，但它们是完全独立的世界。这就像说 Web 开发人员不应该是设计师。也许 SO 只是没有聘请设计师？
我也应该说我也不反对程序员，因为我是其中之一 ;)

【解决方案4】：

桌子并不邪恶，但它们的某些用途（曾经无处不在）是邪恶的。即使用间隔、嵌套单元格等来控制边距和内边距。

尽管现在每个人都在谈论使用 css 和 div 进行布局，但事实是 css 在布局方面很糟糕。你只能做这么多。查看一些建议的解决方案，以使用 css 获得 2 或 3 列布局，它们都很糟糕。投掷<table><tr><td id="left-column"><td id="right-column"></tr></table> 要容易得多。

css 不适合非平凡的布局（我的意思是纯 div/css）

我刚才抛出的表格解决方案需要使用css来控制宽度和内边距以及边框和背景图片等。

【讨论】：

“他们都糟透了”——并非如此……“圣杯”布局：alistapart.com/articles/holygrail
我认为你可以用 CSS 做一些相当复杂的布局。你最后可能没有头发（问我妻子）。
我无法想象为什么有人会认为这个答案令人反感，如果您不同意投反对票但答案没有任何冒犯性。
我假设这是由于原始帖子语言所致。检查编辑。
@SamB，同意，这就是我最初的意思，使用浮动进行布局是邪恶的。

【解决方案5】：

Give up and use tables

【讨论】：

这是错字吧？这不应该写成“放弃……”

【解决方案6】：

因为 Internet Explorer 不支持 display:table CSS 属性，它提供了类似网格的布局模型（相当于 html 表格的呈现方式）。网格模型是对许多布局建模的最简单、最灵活的方法。

所以你有三个选择，没有一个有吸引力：

牺牲对 Internet Explorer 的支持（所有其他现代浏览器都支持 display:table 属性，这已成为 CSS2 标准的一部分已有十多年了）
使用昂贵且难以维护的繁琐 CSS 变通方法。
牺牲语义纯度并使用 TABLE 元素。

SO 选择了最后一个选项，可能是因为他们认为对 Internet Explorer 用户 的支持比对残疾用户 的支持更重要，并且因为他们想要一些可以快速上手的东西开发和维护简单。

【讨论】：

所以你声称 SO 布局不能在没有结构表的情况下用纯粹、有效的 CSS 重新制作？听起来对我来说是个挑战。
不，我声称纯 CSS 解决方案（没有 display:table）会更复杂，更难维护。查看列表中的第二个点 :-)
HTML 表格绝对没有问题 - 用于呈现表格数据。如果您知道自己在做什么，则可以使用 CSS 布局以同样快的速度构建 SO，适用于所有主流浏览器，并且可能占用更小的空间（并且不需要 display:table 或其变通方法）
IE6 确实支持 display:inline-block，它可以轻松地替换这里的一半表格，而且没有草率的解决方法。
多么巧合！我给坚持使用 CSS 的客户打了几乎完全相同的电子邮件。

【解决方案7】：

Jeff 和他的团队做得又快又脏。这是一个非常快速的开发周期，没有时间去重构很多杂乱的东西。

面对现实吧 - 除非您是专家，否则 CSS 对表格结构来说非常耗时。

内联样式和包含的 css 只是他们试图完成它的标志，而不是担心（至少在第一次迭代中）这样做的“正确”方式。正确的方法是任何可行的方法并快速完成。

【讨论】：

如果您不知道自己在做什么，CSS 会很耗时。如果你这样做了，它也一样快，因为你通常会减少打字并花费更少的时间进行维护。快速而肮脏的开发（因为你没有正确完成它的技能）很好，只是不要把它归咎于 CSS。

【解决方案8】：

IE8 将是最后一个支持 CSS 显示的主流浏览器：table-* 值，因此区别将消失。希望这将结束关于 CSS 有多难的抱怨，并且人们可以停止使用演示文稿污染标记。

【讨论】：

除非 IE6 需要 5 年才能完全消亡，而 IE7 需要 10 年，所以也许在 2019 年这将适用：-)
我想你会发现 IE 的使用速度非常快，因为它们会自动推出升级。现在微软正在推出一个实用程序来block 公司的 IE8。环境。
现在是 2010 年的尾声。我仍然从 IE6 获得 25% 的流量，该网站致力于 gasp HTML5 和 SVG 实验！
我觉得这很难相信，因为我工作的 金融机构 的 IE6 大约有 3%。

【解决方案9】：

我是一个相当聪明的人，至少不低于平均水平，但我发现 css 布局完全不直观。表格非常直观。我认为衡量一项好技术的一个指标是您在阅读手册时必须多长时间参考一次手册。与 css 相比，表格以这种方式将 CSS 从水中吹了出来。一次又一次，在使用css的时候，我不得不去挖掘如何去做something like this

【讨论】：

【解决方案10】：

表格和布局

SO 的布局不是基于表格。

快速浏览一下，我会说 SO 布局是 80% 基于 div 和 20% 基于 table。表格用于标题和“徽章”框中。表格使用适用于徽章恕我直言（毕竟这是一个项目列表），对标题不太好。
在其他任何地方，都会使用 div。

内联 CSS

同样，使用了许多内联定义（可能是为了快速模拟网站的结构），但 SO 也正确使用了 css（设置 div 的样式并提供打印格式）。

【讨论】：

咳咳。如果它是一个 list 项目，那么有一个比表格更合适的 list 元素。但我知道什么？
我认为在这种情况下，每行只有一个的表也是可以接受的。无论如何，我们并没有面临“div vs. table”的困境。

【解决方案11】：

“css 太难”和“表格更快更容易”的借口，再加上对使用表格进行结构标记有什么问题的一些完全正确的疑虑。

问题是问为什么 SO 选择使用表、内联 css 等，我认为答案可能无非是他们不熟悉优雅降级和语义，或者他们没有考虑投入时间和资源已经足够重要了。

不知道 css 并没有错，但是仅仅因为你不知道 css 就忽略语义标记和正确使用 css 是错误的。

为了让您的网站在每个使用表格的浏览器中看起来都一样，而对那些不使用可视化浏览器的人毫不留情，这有点自私 - 这是一个强烈的词，我为语气道歉，因为我无意侮辱。

顺便说一句 - 我对使用表格进行结构标记是一场“圣战”的想法感到不满。虽然有些人可能认为语义标记被过度拥护，但它并不是基于盲目的信仰。

【讨论】：

它并不总是基于盲目的信仰——但不幸的是，我发现有很大一部分人接受它...
有些人可能无法清楚地表达他们所理解的内容，但我怀疑他们确实“明白”了。语义标记背后有很多基本原理......

【解决方案12】：

CSS 很棒，可以真正简化您的标记，但是，有时将内容与表格对齐会更容易、更可靠。同样对于动态生成的代码，非基于 CSS 的样式的一些痛点也不那么糟糕。具体来说，由于您是动态创建标记的，因此您可以在功能代码中重构样式元素。

至于内嵌样式，我经常在构建页面时使用它们，然后尝试将它们重新分解为外部工作表。这使我的测试变得更容易（无需进行硬刷新），并且更改在一个文件中而不是两个文件中。

【讨论】：

【解决方案13】：

我的想法是他们会选择表格，因为（除了参数 table vs css）

他们需要快速推出功能以获得意见
毕竟这只是公开测试版。
他们更多地尝试了 ASP.NET MVC，减少了布局问题
SO 完全是关于编程问题和答案，最后才是最重要的。
SO 就是通过奖励积分和徽章来表彰贡献者，它做得相当不错（这也可能是一个有争议的话题）。
等等....

【讨论】：

【解决方案14】：

我不知道，但我能想出的唯一解释是 Jeff 并不像他希望我们认为的那样支持 Web 标准，而且团队中没有人对 CSS 如此热衷。程序员经常使用跨浏览器、易用性和许多其他所谓的时间优势来为他们缺乏 CSS 技能找借口。我并不是说，作为一种批评，他们可能真的很擅长编程 C#/Java/Ruby/SQL/whatever，他们似乎无法承认他们并不像我们一群人那样真正了解某些东西穿着马球领，挥舞着 Mac Book 的设计师......

【讨论】：

当人们说 CSS 方法很难时，他们的真正意思是它很 hacky，因为 A 级浏览器并不始终支持它。查看 JaquesB 的回答