人们为什么要用div制作桌子？

在现代Web开发中，我越来越经常遇到这种模式。看起来像这样：

<div class="table">
    <div class="row">
        <div class="cell"></div>
        <div class="cell"></div>
        <div class="cell"></div>
    </div>
</div>

在CSS中，类似：

.table { display: table; }
.row { display: table-row; }
.cell { display: table-cell; }

^{*（类名仅是说明性的；在现实生活中，这些是反映元素含义的普通类名）}

我什至最近都尝试自己做这个，因为……每个人都在做。

但是我还是不明白。我们为什么要这样做呢？如果您需要一张桌子，那么只需将其炸毁<table>并完成即可。是的，即使是用于布局。那就是表格的用途-以表格形式放置内容。

我最好的解释是，到现在为止，每个人都听过“不要使用表格进行布局”的口号，因此他们盲目地遵循它。但是他们仍然需要一个表格进行布局（因为其他任何东西都不具有表格的扩展功能），所以他们制作了一个表格<div>（因为它不是表格！），然后添加了使其成为表格的CSS。

对我来说，这就像在世界上摆出任意不必要的障碍，然后做额外的工作来规避它们。

离开表格进行布局的原始论点是，之后很难修改表格布局。但是出于同样的原因，修改“仿表”布局也同样困难。实际上，实际上，修改布局总是很困难，而且如果您想做一些比细微调整更严肃的事情，仅更改CSS几乎是远远不够的。您将需要了解和更改HTML结构，以进行认真的设计更改。表格不会比div更难或更容易。

事实上，我看到桌子可以做一个布局很难修改，唯一的办法是，如果你从头使用他们，创造了一个不敬虔的混乱。您也可以使用div来做到这一点。

所以...为了将这个问题从咆哮变成一个连贯的问题：我想念的是什么？使用“人造桌子”而不是真正的桌子有什么实际好处？

关于重复链接：这并不是建议使用其他标签或其他东西。这是关于使用<table>vs 的问题display:table。

这是制作响应表的常见模式。表格数据很难在手机上显示，因为页面将被放大以读取文本，这意味着表格偏离了页面的侧面，用户必须前后滚动才能读取表格，否则页面将被缩小，通常表示表格太小而无法读取。

响应表会更改较小屏幕上的布局-有时隐藏某些列或合并某些列，例如，在大屏幕上名称和电子邮件地址可能是分开的，但在小屏幕上会折叠成一个单元格，因此无需滚动即可读取信息。

<div><table>出于几个原因，使用s代替标签创建表。如果使用了<table>标记，那么在添加自己的代码之前，您需要覆盖浏览器的默认样式和布局，因此，在这种情况下，<div>标记可以节省很多样板CSS。此外，较旧版本的IE不允许您覆盖默认的表格样式，因此使用<div>s还可以简化跨浏览器的开发。

在CSS-Tricks上有一个很好的响应表概述。

编辑：我应该指出，我不提倡这种模式-它落入了divitis陷阱并且不是语义的-但这就是为什么您会发现由divs 制成的表的原因。

问题是，数据在语义上是表（即逻辑上以二维方式组织的一组数据或信息单元），还是仅将网格用于可视布局，例如，因为您希望侧边栏扩展或类似的东西。

如果您的信息在语义上是一个表，则使用<table>-tag。如果您只想为布局目的使用网格，则可以使用其他一些合适的html元素并display:table在样式表中使用。

数据在语义上何时是表格？当数据沿两个轴逻辑组织时。如果对行或列的标题有意义，那么您可能有一个语义表。在语义上不是表格的东西的一个例子是在报纸等列中显示文本。从语义上来说，这不是一个表，因为您仍然可以线性阅读它，并且如果除去演示文稿，也不会失去任何意义。

好的，为什么不对<table>所有内容使用而不是仅对语义上是表的内容使用？在视觉上，它显然是相同的（因为table元素仅display:element在默认样式表中具有）。

区别在于语义信息可以帮助替代用户代理。例如，屏幕阅读器可能允许您在表的两个维度中进行导航，并且如果忘记了所在位置，则可以读取两个轴的单元格标题。如果该表在语义上不是表，而是仅用于可视化布局，这将令人困惑。

在<table>与display:table讨论只是使用语义标记的更一般原则的情况下。例如，请参阅：为什么要打扰正确地和语义地标记？或为什么语义标记被赋予搜索引擎更多的权重？

在某些地方，出于可访问性的原因，实际上可能会法律上要求您使用语义标记，并且在任何情况下都没有理由故意使页面的访问性降低。

即使您不关心残疾用户，将演示文稿与内容分开也能为您带来好处。例如，可以使用替代样式表将三列布局显示在移动设备上的一列中。

实际上，我想说的是，在您的示例中使用“ table”之类的类名说明了人们在尝试语义标记时实际上并不了解他们在做什么。他们因试图表明内容不是表格数据而获得分数，但因类名错误而失去分数。

<div class="table">
  <div class="row">
    <div class="cell"></div>
    <div class="cell"></div>
    <div class="cell"></div>
  </div>
</div>

该开发人员所做的全部工作就是<table>使用CSS类名复制原始标记。这意味着，如果此布局不是表格，则类名是矛盾的。

该开发人员应该做的是考虑表格中的信息-它是缩略图库吗？好吧：

<div class="thumbnail-gallery">
  <div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
    <div class="thumbnail">
      <img src="" />
      <p>Some text</p>
    </div>
  </div>
</div>

现在，我可以创建一些自适应CSS：

@media screen {
  .thumbnail-gallery {
    display: table;
    border-collapse: collapse;
    width: 100%;
  }

  .thumbnail-gallery > div {
    display: table-row;
  }

  .thumbnail-gallery .thumbnail {
    display: table-cell;
    border: 1px solid #333333;
  }
}

@media screen and (max-width: 640px) {
  /** reset all thumbnail gallery elements to display as block and fill screen **/
  .thumbnail-gallery,
  .thumbnail-gallery > div,
  .thumbnail-gallery .thumbnail {
    display: block;
    width: 100%;
  }
}

为什么使用div而不是表格

表格包含表格数据 - 表格的显示与表格的结构紧密相关。无论您将内容放在何处或要在哪个屏幕/设备上显示，表格数据始终都必须采用表格形式。

缩略图库（或许多其他东西，例如注册表单，菜单等）不是表格数据。在某些设计布局中，它可能像表格一样显示，但是在其他情况下，例如狭窄的电话屏幕，您希望它使用更传统的块布局。或者，您可能想在侧栏中而不是在主内容区域中显示缩略图。

现在，您的选择是为宽屏内容（表）和侧边栏或窄屏内容（div）输出不同的标记-这意味着如果您以编程方式构建此内容，则服务器端脚本将必须知道内容的去向-或者您让服务器端脚本输出相同的标记（因为它不必关心将其放置在何处），并针对不同的情况使用不同的CSS规则。

因此，您可以选择始终输出表，然后使用块覆盖自然的表显示规则（这实际上应该在任何开发人员的脑海中磨碎一些齿轮），或者选择带有标签的div，以便使用更灵活的样式方法。

而几年来的最佳做法现在已经避免不需要提交表格数据时表。

在过去，当使用百分比表示列宽时，表呈现引擎“ 出现 ”的速度变慢。引擎必须先下载整个数据集，然后才能开始计算将其绘制在屏幕上的大小。

DIV引擎是不同的。当浏览器遇到DIV时，它将继续放置它并开始内联填充内容。当然，随着数据加载完成，div可能会跳来跳去。因此，为什么我出现在上面的引用中。两者完成的时间框架是相同的，但是直到结束时才绘制表格，这意味着用户不确定一两秒钟是否正在加载。

随着表格的嵌套，情况变得更糟。

那时（并且仍然存在）使表渲染FAR FAR更快的方法。基本上是通过提示列大小没有变化，然后浏览器立即开始呈现表格数据。最终，这意味着表格实际上可以比div 更快地显示在正确的位置，从而使表格看起来更好。

但这还不是全部。剩下的就是大多数开发人员根本就不花时间去学习足够的技巧来了解这一点。取而代之的是，他们跳上各种潮流，并采用了可以复制/粘贴的任何代码。即使在今天，我仍然发现几乎没有Web开发人员知道一种文档类型与另一种文档类型之间的区别-这就是为什么各种站点具有涵盖各种浏览器的各种变通办法的第一原因。

因此，+ 1向您提出问题。

如果我可以在这里获得一些“元”，这将给我带来两个问题：

一个：有人出于某种充分的理由提出一条规则，而人们在忽略规则精神的同时遵循规则的技术字母，从而完全忽略了要点。他们找到了一种方法来完成规则试图防止的所有不良行为，同时在技术上仍遵循措词。

二：有人看到问题并提出预防规则。其他人看到此规则的价值。然后，他们坚持盲目地奉献给该规则，而不考虑它原本应该解决的问题和/或不管它造成了什么其他问题。我有很多谈话，有人说：“那是必须的，所以你必须做X。”然后我问：“为什么我们要做X？”，他们满脸沮丧地看着我，说：“但是我只是告诉你！因为这是规则！” 我回答说：“但这似乎引起的问题多于解决的问题。我认为我们最好做Y。” 然后那个人说：“不，看，我给你看。看，就在这本书中。X是规则。”

在这种情况下，我们有一个问题：table标记有两件事：第一，它控制文档的布局。第二，它传达了这样一个想法，即封闭的数据由数字或其他数据的行和列组成。

有很多人提出了解决方案：不要使用表格标签来控制逻辑上不是“表格”的事物的布局。使用CSS。

但是此解决方案存在问题。table标签及其子标签具有许多非常有用的布局功能，这些功能使用CSS并不容易实现，而当实现这些功能时，执行此操作所需的代码通常很麻烦-难以阅读且难以维护。如果有一种干净，简便的方法，为什么我们要以笨拙，困难的方式处理事情？

就个人而言，我认为最好声明一下：“表标记中包含某些内容的事实并不一定意味着它代表数字的行和列”。这不会是一个令人发指的声明。我从未听说过有人说“ p”标记只能用于那些确实是语法正确，逻辑构造的英语句子段落的东西。我从未听说有人说过，对列表使用“ ul”标签是错误的，实际上，列表确实是按逻辑顺序排列的，只是因为您需要项目符号而不是序列号。等等。

目前已经吨这里伟大的答案的。但是我想补充一点，table元素具有渲染限制，而这些限制对于div元素而言是不存在的。尝试制作一个进行虚拟滚动的表（例如：SlickGrid，DataTables等），您会非常失望。就是行不通。大多数（全部？）现代Javascript网格都使用divs，因为css允许更灵活的呈现。

还有其他限制。我的一般规则是，如果要在单个屏幕上查看整个表格，并且不希望使用任何/太多自定义渲染，则可以使用table元素，否则我可以使用div，因为我可以控制很多结果，轻松得多。

HTML和CSS已经发展了一定程度的灵活性，这意味着即使从概念上讲，“块”元素<div>（例如HTML最古老和最通用的块内容形式）也无需显示为块：

div { display: inline; }

如您所述，<div>可以将其重新用于模仿<table>其同伴。实际上，大多数标签都可以。鉴于其特殊的角色，我怀疑你能有效地重新映射宏标签，如<html>， <head>，<body>，和<script>，但“普通”之类的标签<div>，<p>，<b>，<em>，<span>，和<pre>？争抢。使内联标签块，内联块，预格式化标签流动，固定标签浮动。疯了，如果你喜欢！

有可能。您可能要分拆我们应该如何都使用“语义标记”等等等等纱等等，或认为与Pythonistas说：“应该有一个-并且最好只有一个-明显的方法来做到这一点。” 然而蒂姆·托迪（Tim Toady）是一个聪明而好奇的家伙。有空的时候，他将探索所有这些。这包括使用可用的灵活性进行替换。有些是明智的，有些将得到证明。但是，尝试，错误和经验是找出答案的唯一方法。因此存在足够的替代条件。

我认为替代也是必要的，这一点并不为过。至少，这非常方便。长期以来，HTML没有<menu>，<section>或<aside>元素。但是，到处都有网页和应用程序都有菜单，部分和侧边栏。怎么样？因为HTML列表元素（<ul>，<ol>和<li>）很容易重新利用，并且某些用法重新分类为菜单容器和部件。<div>可以站在为<article>，<section>，<aside>，<figure>，和<summary>。HTML5已经赶上了一些以前未解决的用例，并为其添加了定制元素。这是一个很好的更新和更正，可以适应常见的实际使用情况。

即便如此，仍然存在许多没有定制标签或语义模型的常见习语。我和许多其他人每天使用的内容，例如页面，脚注，引号，注释流，关联的头像，“喜欢”，副标题和字幕。我们接下来干吗？我们能做到的。使用类和ID重新调整“接近但不精确”的元素的用途，以支持并支持我们在接下来的五到十年甚至很多年的工作，直到HTML6或HTML7赶上来。HTML / CSS的“是的，从理论上讲它是一个X，但是我们要标记它并以Y的形式使用它”功能非常方便。必不可少，真的。它使Web内容具有灵活性，并且不会变脆。

更进一步，“语义标记”具有不可简化的局限性。对于内容您可以想象的任何一种严谨的结构都是如此。

标准格式不能涵盖人类需求，欲望和多样性的全部财富。他们将永远会是一个什么人在做“背后的曲线” 现在。他们如何创新。哎呀，HTML5在脚注，小标题和其他17世纪印刷创新方面仍然落后。它缺少许多信息工作者和内容创建者必不可少的功能。所以我们即兴创作。

更加不变的是，信息不遵守一套规则。当然，它以表格开始。但是也许您只需要摘要-以列表的形式列出每一行的标题。也许它占用了太多空间，并且您希望将其作为节省空间的内联列表。也许您有只想要标题的记录，然后单击，就可以看到基本的详细信息。或者，您希望将复杂列表或表格中的项目进行分组和分类。哦，现在您希望它以不同的方式进行转置和分类。或以条形图绘制的值。这些都是每天在应用程序，电子表格和数据可视化中完成的工作。它们是我们信息环境以及我们想要和需要在网络上进行的工作的一部分。人类不断地重组我们数据的形式和表示方式。这不只是一件事，也不是一种格式/布局，或一个概念。它是可替代的，其语义取决于情况和用户交互做出的选择。是的，将文本标记为“强调”（<em>），但这只是一个约定。我处理的文档至少有六种不同的“重点”。我们需要能够针对不同用途，不同解释进行自定义和重新映射。一种HTML强调？简直是还原主义。限制。脆。同样是真正的<table>，<p>等等。

拥有标签/元素可以帮助组织整个社区对“前进的方向”的思考，真是太好了。这有助于建立惯例和习惯用法，并使我们集体更有效率。但是，能够重新映射事物，重新指定和重新利用那些结构的功能吗？这是网络的包容性及其成功的重要组成部分。

用例很重要。内容页面和应用程序中的布局/表示形式之间存在很大差异。在内容上，语义对于SEO意识和可用性至关重要。在这些情况下，使用表来呈现表格数据通常是正确的选择。正如其他人指出的那样，如果法规要求您遵守政府可用性指南，那么搜索引擎将对您进行处罚，您甚至可能违反可用性法律。

在Web应用程序中，开发人员可能会出于SEO和可用性的目的而选择创建完全独立的视图。响应式设计导致人们构建可以处理桌面和移动版式的视图，在这些用例中，div比表更好。

以电子商务网站为例。通常，在浏览或搜索结果中查看产品列表会以表格形式显示产品列表，但是这些视图很可能是使用div（提供更通用，更灵活的布局和样式选项）而不是表格生成的。亚马逊和eBay就是这种方法的典范。在任一站点上检查搜索结果，您将看到一组深层嵌套的div。