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

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


在CSS中有类似的东西：名称仅是说明性的；在现实生活中，它们是正常的类名称，反映了元素的含义。

我最近甚至亲自尝试过这样做，因为...您知道，每个人都在这样做。
但是我还是不明白。我们为什么这样做呢？如果您需要一张桌子，那么只需做一个爆裂的<table>即可完成。是的，即使是用于布局。这就是表格的用途-以表格形式放置内容。它瞎了。但是他们仍然需要一个表格进行布局（因为其他任何东西都不具有表格的扩展功能），所以他们制作了一个<div>（因为它不是表格！），然后添加CSS使其成为表格。

对于我来说，这对我来说就像是在摆放任意不必要的障碍物，然后再做额外的工作来规避它们。

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

所以...为了将这个问题从咆哮变成一个连贯的问题：我想念的是什么？在真正的表上使用“仿表”的实际好处是什么？

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

评论

@JuhaUntinen：那……听起来不太可能。来源？
@ PaulD.Waite-我认为今天实际上仍然如此。阅读其他答案。除非该表具有table-layout：fixed，否则它将需要完全加载后才能显示。使用现代宽带时，这种影响几乎不那么明显。
@JuhaUntinen：这并不完全准确。当您使用百分比表示列宽时，表格渲染引擎会变慢，因为必须先下载整个表格，然后浏览器才能开始弄清楚要制作多大的东西。嵌套表使这变得过于复杂。但是，存在（并且仍然存在）使表呈现FAR FAR更快的方法。很少有开发者会花时间去学习足够的技巧，而跳入潮流。
在更早的日子里，我们曾经使用表来模仿div，所以在那里。
有人读到他们不应该使用表格进行布局，并认为这根本不应该使用表格。我讨厌这种趋势。

#1 楼

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

响应式表格会在较小的屏幕上更改布局-有时隐藏某些列或合并某些列，例如在大屏幕上，名称和电子邮件地址可能是分开的，但是在小屏幕上，名称和电子邮件地址会折叠成一个单元格，因此无需滚动即可读取信息。有几个原因。如果使用<div>标签，那么在添加自己的代码之前，您需要覆盖浏览器的默认样式和布局，因此，在这种情况下，<table>标签可以节省很多样板CSS。此外，旧版的IE不允许您覆盖默认的表格样式，因此使用<table> s也可以简化跨浏览器的开发。 br />
编辑：我应该指出，我不主张这种模式-它属于divitis陷阱并且不是语义的-但这就是为什么您会发现使用<div> s制成的表的原因。 />

评论

我接受这个答案，因为似乎没有其他有用的东西了。有较高的投票答案，但他们基本上说“因为语义”（并且它们可以提供语义的唯一原因是屏幕阅读器，这并不能说服我）。 @HorusKol的答案在您之前提到了响应能力，但您的意义更重要。如果将来出现更好的答案，我将其更改为公认的答案。

– Vilx-
2015年4月3日23:10
这是荒谬和懒惰的。您使用
“表”所做的任何事情都可以用常规表完成，因此，除了旧的IE版本和惰性，几乎没有理由使用非语义元素来构建表。也就是说，实际的表格数据在互联网上似乎很少，因此也许这不是问题。

–您
2015年4月4日在9:17
@Vilx：您提出的问题是“为什么人们用divs制作桌子”，这就是您得到的答案。例如，您可能并不在乎屏幕阅读器，但这并不能改变可访问性是许多人真正关心的问题，并且（与搜索引擎一起）是许多人选择语义HTML的主要原因。

–雅克B
15年4月4日在19:07
出于所有意图和目的，这是完全错误的。如果您的数据是表格形式的，则将其放在表中。 BS声称表在移动设备上的行为尤其有害。您可以像使非表元素具有表值一样轻松地将表元素的显示属性更改为非表值。

–cimmanon
15年4月4日在19:08
我相信这个答案有点误导。响应式表的设计很好，但是它与使用或
的问题无关-您可以使用任一表来获得相同的视觉效果。实际上，这是结构和表示分离的思想的核心。的确，较旧版本的IE不允许覆盖表样式，但是较旧版本的IE也不支持display：table，因此您不能以任何方式使用响应表。

–雅克B
15年4月4日在19:39

#2 楼

问题是，数据是否在语义上是一个表（即逻辑上以二维方式组织的一组数据或信息单元），或者您只是将网格用于可视布局，例如因为您希望侧边栏展开或类似的事情。如果只想使用网格进行布局，则可以使用其他一些合适的html元素，并在样式表中使用<table>。

数据在语义上何时是表？当数据沿两个轴进行逻辑组织时。如果对于行或列的标题有意义，那么您可能有一个语义表。在语义上不是表格的某事的示例是在报纸等列中显示文本。从语义上讲，这不是一个表，因为您仍然可以线性读取它，并且如果删除了演示文稿，也不会失去任何意义。对于语义上是表格的东西？视觉上显然是相同的（因为table元素在默认样式表中只有display:table）。

不同之处在于语义信息可以帮助替代用户代理。例如，屏幕阅读器可能允许您在表的两个维度中进行导航，并且如果忘记了所在位置，则可以读取两个轴的单元格标题。如果该表不是语义上的表，而只是用于可视化布局，那么这将令人困惑。
举个例子：为什么要打扰正确和语义地标记？或为什么语义标记在搜索引擎中得到更大的重视？

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

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

评论

@ Vilx-为什么使用和而不是和？因为和与标记的语义无关。
具有语义。将其用于不是表格的内容会更难于理解文档的语义。

–user40980
15年3月30日在18:54
@ Vilx-这本书 Peoplesoft 是该主题的最佳书。将放在最佳位置将是错误的，因为这意味着与围绕书名的内容有所不同。有关更多信息，请参见为什么不推荐使用和标签？ 和，和有什么区别？

–user40980
2015年3月30日19:18


如果您不在乎内容的含义，强烈建议您停止使用除表单和div之外的任何元素。只需添加类即可应用样式和行为。

– Rich Remer
15年3月30日在22:45
@ Vilx-：当您说您关心用户的体验时，您似乎只表示您的部分用户。按照您所描述的方式正确使用标记的主要原因是可访问性，它直接与残疾用户的用户体验有关。这些人会从您以正确的方式做事中受益，而忽略这些约定意味着可能会使他们的网络体验变得更加困难。

–rooby
15年3月30日在22:55
@ Vilx-，是的，屏幕阅读器确实将
与
区别对待。
通常被忽略并按顺序读取。在
内部，它必须提供不同的导航击键/命令（“跳至右侧的单元格”，“读取列和行标题”等），并发出不同的位置信息（当读取流进入表时）它的内容类似于“表3，第1行第1列，Lorem Ipsum dolor ...”）

–Euro Micelli
2015年3月31日，0：12


#3 楼

实际上，我想说的是，在您的示例中使用“ table”之类的类名演示了人们在尝试语义标记时实际上并不了解他们在做什么。他们因为试图表明内容不是表格数据而获得了标记，但是由于类名不正确而失去了商标。带有CSS类名称的原始<table>标记。这意味着，一旦此布局不是表格，则类名就矛盾了。好吧，那么：

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


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

表包含表格数据-表的表示与表的结构紧密相关。无论您将内容放在何处或要在哪个屏幕/设备上显示，表格数据都始终需要以表格形式显示。 ，菜单等）不是表格数据。在某些设计布局中，它可能像表格一样显示，但在其他情况下，例如狭窄的电话屏幕，您希望它使用更传统的块布局。或者，您可能希望在侧栏中而不是在主内容区域中显示缩略图。

您现在的选择是为宽屏内容（表）和侧栏或窄屏内容（div）输出不同的标记-这意味着您的服务器端脚本将必须知道内容的位置如果您以编程方式构建它，或者您的服务器端脚本输出相同的标记（因为它不必在意放置此标记），并针对不同的情况使用不同的CSS规则，那么该操作就可以了。

因此，您可以选择始终输出表，然后使用block覆盖自然的表显示规则（实际上应该在任何开发人员的头上磨一些齿轮），或者选择标签明确的div，以便使用更灵活的样式方法。 br />
几年来的最佳实践是在不需要显示表格数据时避免使用表。

评论

类名实际上只是一个例子。在现实生活中，它们大多具有适当的描述性。无论如何，在您的示例中，为什么使用
代替
？它提供什么好处？

– Vilx-
15年3月30日在23:02
嗯...嗯，在您的情况下，您实际上是通过媒体查询对同一HTML进行两种不同的表示形式。好的，这是一个很好的用例。但是，如果不是这种情况，并且您事先已经知道该缩略图库将仅在一个位置以表格格式显示-您会使用
然后还是display：table？因为从某种意义上讲，它是表格数据。除了“数据”是图片，但仍然如此。

– Vilx-
15年3月30日在23:22
好吧，不，它不是表格数据。您将其呈现在类似于表格的网格中。表格数据是统计信息和比较信息-像电子表格一样思考。您是否会说Windows文件资源管理器中的缩略图视图是表格数据？而且，这总是会像桌子一样呈现吗？如果要在6或12个月内使用其他视图样式该怎么办？为什么要面对被广泛接受的做法而固执己见，实行具有长期影响的限制？

–HorusKol
15年3月30日在23:26
完全不是表格数据。除了任意布局决定外，没有其他理由使此内容类似于表格。它不是列和行中的结构化数据，而是内容的列表，排列在网格中。 -编辑：HorusKol说了什么。

–埃里克·金（Eric King）
2015年3月30日23:27


好吧，那有点困难了。 :)好吧，您给了我一些思考！谢谢你！我仍然不是100％相信，但是至少可以继续。 :)

– Vilx-
15年3月30日在23:43

#4 楼

在过去，使用百分比表示列宽时，表呈现引擎“显示”的速度变慢。该引擎本质上必须先下载整个数据集，然后才能开始计算将其绘制在屏幕上的大小。当浏览器遇到DIV时，它将继续放置它并开始内联填充内容。当然，随着数据加载完成，div可能会跳来跳去。因此，为什么我出现在上面的引用中。两者完成的时间框架是相同的，但是直到结束时才绘制表格，这意味着用户不确定一两秒钟是否正在加载。更糟糕的是，表格被嵌套。

那时（并且仍然存在）使表渲染FAR FAR更快的方法。基本上是通过提示列大小没有变化，然后浏览器立即开始呈现表格数据。最终，这意味着表格实际上可以比div更快地显示在正确的位置，从而使表格看起来更好。剩下的就是大多数开发人员根本就不花时间去学习足够的技巧来了解这一点。取而代之的是，他们跳上各种潮流，并使用了可以复制/粘贴的任何代码。即使到了今天，我仍然发现很少有Web开发人员知道一种文档类型与另一种文档类型之间的区别-这就是为什么各种网站都具有涵盖各种浏览器的各种变通办法的首要原因。
因此， +1向您提出问题。

评论

关于DOCTYPE的话题：我认为，尽管存在理论上的差异（验证者对此非常重视），但实际上浏览器并没有真正区分它们。好的，也许HTML / XHTML风格之间有一些细微的变化，但是至少没有使用版本和DTD信息。这就是HTML5还是放弃整个内容并只添加<！DOCTYPE html>的原因，这就是为什么它甚至在IE6之类的旧浏览器中也能正常工作的原因。我错过了什么吗？

– Vilx-
2015年4月1日在16:15


@Vilx：doctype将浏览器置于特定模式。除其他外，它定义了使用中的盒子模型。对于许多文档类型，由于使用的盒子模型不同，因此浏览器没有排列在一起。这就是为什么许多开发人员抱怨浏览器显示页面的方式不同，而不是修复文档类型，而是使用了大量的CSS重置表的原因。但是，有一些文档类型，其中所有浏览器都使用相同的盒子模型-但是它们从来都不是默认的，您必须了解它们。

–NotMe
15年4月2日在19:52
@vilx：html 5并没有删除整个内容。而是添加了一个新的文档类型。关键是，出现在html文档顶部的第一行非常关键，如果您不了解它的功能以及各种浏览器的反应方式，那么您将花费太多时间弄清楚为什么布局在特定浏览器中被“破坏”。

–NotMe
15年4月2日在19:57
@Vilx：这有点复杂，因为某些doctypes会触发怪癖模式（与没有doctype相同），而另一些doctypes（包括html5 doctype）会触发标准模式，甚至有些文档类型会触发第三种“几乎标准” ”模式在某些浏览器中。

–雅克B
2015年4月4日19:46


@Vilx：不。几个简单的div带有边界，填充，边距和一些文本的区别将非常明显。最主要的是盒子模型如何工作。大多数情况下，人们尝试通过使用css重置表（试图将边距和填充设置为零）来补偿糟糕的文档类型选择。

–NotMe
2015年4月8日14:40在

#5 楼

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

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

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

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

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

但是此解决方案存在问题。 table标签及其子标签具有许多非常有用的布局功能，这些功能使用CSS并不容易实现，而当实现这些功能时，执行此操作所需的代码通常很麻烦-难以阅读且难以维护。如果有一种干净，简便的方法，为什么我们要以笨拙，困难的方式处理事情？就个人而言，我认为最好声明一下：“表标记中包含某些内容的事实并不一定意味着它代表数字的行和列”。这不会是一个令人发指的声明。我从未听说过有人说“ p”标记只能用于那些确实是语法正确，逻辑构造的英语句子段落的东西。我从未听说有人说过，对确实以逻辑顺序出现的列表使用“ ul”标记是错误的，只是因为您需要项目符号而不是序列号。等

评论

到最后一段-您已经阅读了这些元素的HTML5规范，不是吗？ w3.org/html/wg/drafts/html/master/semantics.html#the-p-element w3.org/html/wg/drafts/html/master/semantics.html#the-ul-element w3.org/ html / wg / drafts / html / master / semantics.html＃the-ol-element-特别是如果顺序很重要，则使用ol元素（因为这是结构性部分）-您仍然可以将其作为项目符号列表显示使用CSS

–HorusKol
15年3月31日在22:47
如果您在这里查看其他两个答案，您会发现它们都不会简单地说“因为这是规则”-它们都为规则和用例提供了非常明确的理由

–HorusKol
15年3月31日在22:48
嗯，在我看来，我说的是：“有人看到了一个问题，并提出了预防该规则的规则。其他人则看到了该规则的价值。然后，他们坚持盲目地奉献于该规则，而不考虑最初的问题解决和/或不管它造成了什么其他问题。”我不否认规则背后有合理的思考。我只是不同意结论。我当然可以说：“您在这里有个不错的主意，但我不同意。”当然，您不会否认有些人不了解优缺点，并说...

–杰伊
2015年4月1日13:35
...“因为这是规则”。多年来，在这个特定问题上，我还与这些人进行过多次对话。拒绝讨论规则的利弊的人，因为这是规则，是讨论的结尾。

–杰伊
2015年4月1日于13:37
不幸的是，HTML设计起源于某种抽象形式的工程而非艺术。因此，从某种意义上说，有人决定必须有一个类似于物理学的绝对规则，必须遵守重力，否则违反这些规则的人就会脱离“纯粹的信仰”。现实是，没有浏览器或设计隐喻是绝对可靠的。坚持反对的人要谨慎行事。

– David W
2015年4月4日在17:52

#6 楼

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

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

#7 楼

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

<如前所述，div { display: inline; } 可以用于模拟<div>及其同行。实际上，大多数标签都可以。鉴于它们的特殊作用，我怀疑您是否可以有效地重新映射诸如<table>，<html>，<head>和<body>的宏标签，但是可以像“ <script>”，“ <div>”，“ <p>”，“ <b>”，“ <em>”和“ <span>”这样的“通用”标签重新映射？争抢。使内联标签块，内联块，预格式化标签流动，固定标签浮动。如果愿意的话，快疯了！

有可能。您可能想绕开我们应该如何使用“语义标记”等等的话题，或者与Pythonistas一起相信“应该有一种-最好只有一种-显而易见的方法”。然而蒂姆·托迪（Tim Toady）是一个聪明而好奇的家伙。有空的时候，他将探索所有这些。这包括使用可用的灵活性进行替换。有些是明智的，有些将得到证明。但是，尝试，错误和经验是找出答案的唯一方法。因此存在足够的替代条件。

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

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

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

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

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

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

评论

在接近答案的地方怎么走？

–HorusKol
15年3月31日在22:51
IMO讨论了一个根本问题，即为什么设计师，开发人员和内容工作者选择使用通用元素（
和）代替特定的，专门构建的元素（例如
）。它不仅仅是这些标签的元数据，但它直接说明了使用的模式和原理。

–乔纳森·尤尼斯（Jonathan Eunice）
15年3月31日在23:07
@HorusKol实际上，在这里所有的答案中，这一答案与您的答案最为一致和支持。我会说它们啮合得很好。

–乔纳森·尤尼斯（Jonathan Eunice）
15年3月31日在23:20
我不知道是否可以将div（作为通用）与table（作为专用）进行对比。它们都是专用的，用于两个不同的（但可能是部分重叠的）目的。我认为，这是问题的核心。

–埃里克·金（Eric King）
15年3月31日在23:37
@EricKing可以公平地说div是有目的的。但是div和span没有table，thead，td等具有非常特定的预期目的。如果您将杂项div元素用于边栏，拉引号，节分组等，也没人会惊慌失措-在文档中的任何地方也是如此。尝试使用未封闭的thead，td或li进行操作。代替“专门构建”，可以是“特定目的”或“具有特定预期角色”。

–乔纳森·尤尼斯（Jonathan Eunice）
2015年3月31日23:51


#8 楼

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

在Web应用程序中，开发人员可能会选择创建出于SEO和可用性目的完全独立的视图。响应式设计导致人们构建可以处理桌面和移动版式的视图，在这些用例中，div比表格更好。例如，以电子商务网站为例。通常，在浏览或搜索结果中查看产品列表会以表格形式显示产品列表，但是这些视图很可能是使用div（提供更通用，更灵活的布局和样式选项）而不是表格生成的。亚马逊和eBay是这种方法的典范。在任何一个站点上检查搜索结果，您都会看到一组深层嵌套的div。

本文标签： html css
为什么不是所有公司都购买最好的硬件给开发人员？
测量经纬度的准确性？
最近发表
随机文章