查看 Stack Overflow 的源代码，我注意到他们使用了很多表格和内联 CSS，我发现奇怪的是使用内联表格属性格式。
<table width="100%">
我只是好奇他们为什么使用表格来构建他们的模板而不是流行的（或曾经流行的）DIV 是否有任何特定的原因。
同样......使用CSS的目的包括在同一页面上使用内联CSS（我知道可能有一个很好的答案/解决方案......我只是好奇它们是什么）
我知道将表格用于表格数据没有任何问题......但在这种情况下，Stack Overflows 表格用于结构。
Tables vs. Divs 是一场毫无意义的圣战。
以特定方式使用表格进行布局存在特定问题，可能会导致问题。其中之一是在单个表格中构建整个站点布局，以处理边距和位置 - 由于表格的呈现方式，这经常意味着网站不会在内容下载时由浏览器引擎逐步呈现，并且只能在收到整个东西后渲染。对于大页面或慢速调制解调器用户，他们可能会长时间盯着空白页面，这是“坏事”。不要介意在 mozilla/ie5 一代浏览器中表格呈现的许多不一致，这使得一致的跨浏览器表格布局有些痛苦，尤其是单元格中的图像。
纯 div 路径的支持者喜欢谈论内容与表示，因为理论上 HTML 4.01 是纯内容，所有这些都是有意义的。div 提供了抽象意义上的有意义的组织结构，然后由 CSS 独家呈现。在这些参数中，表仅在用于包含实际表格数据时才有效。当然，这忽略了这样一个事实，即对于任何足够复杂的布局，几乎总是有相当多的空 div 漂浮在周围，只是为了支持呈现 CSS 的必要钩子，打破了这种抽象的第一层。一旦这种抽象被破坏，就没有法律规定，当您的布局只需要 HTML 中没有有意义的内容的表示挂钩时，div 在某种程度上比 table 更合适。
最后，它是关于了解所有方法的局限性并使用最合适的方法。在很多情况下，使用表格比设置无意义（即无内容意义）的 div 数组更容易，并且表格呈现限制不适用。如果表格很小并且代表内部内容的一小部分，则渲染延迟无关紧要。
没有参与过SO开发，我只泛泛的说一下：
我发现跨浏览器通常比基于 - 的布局tables更容易且更一致。CSS
CSS此外，在尝试完成任务时经常会出现随机发射。我想它可以在以后重构。
至于他们为什么选择在 HTML 而不是 CSS 中设置表格的宽度，我不能说。
我知道 SO 在开始时使用了一位真正的、诚实的设计师。不过，我不知道那个设计师是否给了他们网站应该是什么样子或实际标记的图像。
请不要因为我这么说而激怒我。我们不都是 CSS 忍者。
SO 可能是由程序员编写的，而不是 Web 开发人员。
桌子并不邪恶，但它们的某些用途（曾经无处不在）是邪恶的。即，使用分隔符、嵌套单元格等来控制边距和填充。
尽管现在每个人都在谈论使用 css 和 div 进行布局，但事实是 css 在布局方面很糟糕。你只能做这么多。查看一些建议的解决方案，以使用 css 获得 2 或 3 列布局，它们都很糟糕。投掷a<table><tr><td id="left-column"><td id="right-column"></tr></table>要容易得多。
css 只是不适合非平凡的布局（我的意思是纯 div/css）
我刚才抛出的表格解决方案需要使用 css 来控制宽度和填充以及边框和背景图像等。
因为 Internet Explorer 不支持display:table CSS 属性，它提供了类似网格的布局模型（相当于 html 表格的呈现方式）。网格模型是对许多布局建模的最简单、最灵活的方法。
所以你有三个选择，没有一个有吸引力：
display:table属性，这已成为 CSS2 标准十多年的一部分）SO 选择了最后一个选项，可能是因为他们认为对Internet Explorer 用户的支持比对残疾用户的支持更重要，并且因为他们想要快速开发和易于维护的东西。
我是一个相当聪明的人，至少不低于平均水平，但我发现 css 布局完全不直观。表格非常直观。我认为衡量一项好技术的一个指标是您在阅读手册时必须多久参考一次。与 css 相比，表格以这种方式将 CSS 从水中吹了出来。一次又一次，在使用 css 时，我不得不挖掘以弄清楚如何做这样的事情
IE8 将是最后一个支持 CSS 显示的主要浏览器：table-* 值，因此区别将消失。希望这将结束关于 CSS 有多难的抱怨，人们可以停止用演示文稿污染标记。
杰夫和他的团队正在快速而肮脏地完成它。这是一个非常快速的开发周期，没有时间重构大部分混乱。
面对现实吧——除非你是专家，否则 CSS 对表格结构来说非常耗时。
内联样式和包含的 css 只是他们试图完成它的标志，而不是担心（至少在第一次迭代中）这样做的“正确”方式。正确的方法是任何可行的方法并快速完成。
表格和布局
SO的布局不是基于表格的。
快速浏览一下，我会说 SO 布局是 80% 基于 div 和 20% 基于 table。表格用于标题和“徽章”框。表格使用适用于徽章恕我直言（毕竟它是一个项目列表），对标题不太好。
在其他任何地方，都会使用 div。
内联 CSS
同样，使用了许多内联定义（可能是为了快速模拟站点的结构），但 SO 也正确使用了 css（设置 div 的样式并提供打印格式）。
“css 太难了”和“表格更快更容易”的借口，再加上对使用表格进行结构标记有什么问题的一些完全正确的疑虑。
问题是问为什么 SO 选择使用表、内联 css 等，我认为答案可能无非是他们不熟悉优雅降级和语义，或者他们认为它不够重要投入时间和资源。
不知道 css 并没有错，但是仅仅因为你不知道 css 就忽略语义标记和正确使用 css 是错误的。
提倡您的网站在每个使用表格的浏览器中看起来都一样，同时不考虑那些不使用可视化浏览器的人有点自私 - 这是一个强烈的词，我为语气道歉，因为我不'不打算侮辱。
顺便说一句 - 我对使用表格进行结构标记是一场“圣战”的想法感到不满。虽然有些人可能认为语义标记被过度支持，但它并不是基于盲目的信仰。
我不知道，但我能想到的唯一解释是 Jeff 并不像他希望我们认为的那样支持 Web 标准，而且团队中没有一个人对 CSS 如此热心。程序员经常使用跨浏览器、易用性和许多其他所谓的时间优势来为他们缺乏 CSS 技能找借口。我并不是说，作为一种批评，他们可能真的很擅长编程 C#/Java/Ruby/SQL/whatever，他们似乎无法承认他们并不像我们一群人那样真正了解某些东西穿着马球领，挥舞着 Mac Book 的设计师......
我的想法是他们会选择表格，因为（除了参数表 vs css）
CSS 很棒，可以真正简化您的标记，但是，有时将内容与表格对齐更容易、更可靠。同样对于动态生成的代码，非基于 CSS 的样式的一些痛点也不那么糟糕。具体来说，由于您是动态创建标记的，因此您可以在功能代码中重构样式元素。
至于内联样式，我经常在构建页面时使用它们，然后尝试将它们重新分解为外部工作表。这使我的测试变得更容易（无需进行硬刷新），并且更改在一个文件中而不是两个文件中。