人们普遍认为，不应在HTML中使用表格进行布局。

为什么？

我从来没有(或者说实话很少)对此有很好的论据。通常的答案是：

• 将内容与布局分开是很好的，但这是一个谬论。陈词滥调的思考。我想这是真的，使用表格元素进行布局与表格数据关系不大。所以呢？我的老板在乎吗？我的用户在乎吗？也许是我或者我的同伴开发人员，他们必须维护网页……表的维护性较差吗？我认为使用表格比使用div和CSS更容易。顺便说一句...为什么使用div或者span不能很好地将内容与布局和表格分开？仅使用div获得良好的布局通常需要很多嵌套的div。
• 代码的可读性我认为是相反的。大多数人了解HTML，很少人了解CSS。
• SEO最好不要使用表，为什么呢？有人可以证明它是吗？还是Google的声明，即从SEO角度不鼓励使用表？
• 表比较慢。必须插入一个额外的tbody元素。这是用于现代Web浏览器的花生。向我展示一些基准测试，其中使用表会显着降低页面速度。
• 没有桌子，布局检修会更容易，请参见css Zen Garden。大多数需要升级的网站也需要新内容(HTML)。新版本的网站仅需要新的CSS文件的情况不太可能发生。 Zen Garden是一个不错的网站，但是有点理论化。更不用说它对CSS的滥用了。

我对使用divs + CSS而不是表的好参数很感兴趣。

解决方案

回答

表很适合将HTML组合在一起用于简单或者临时的操作。如果要构建大型网站，则应使用divs和CSS，因为随着网站的更改，随着时间的推移，维护起来会更加容易。

回答

根据508规范(对于有视觉障碍的屏幕阅读器而言)，表格仅应用于保存数据，而不能用于布局，因为它会导致屏幕阅读器出现异常。还是有人告诉我。

如果为每个div分配名称，则也可以使用CSS将它们全部换肤。要让他们按自己的方式坐下来，他们会感到有些痛苦。

回答

无论如何，这不是确定的参数，但是使用CSS，我们可以采用相同的标记并根据媒介更改布局，这是一个很好的优势。例如，对于打印页面，我们可以安静地禁止导航，而不必创建易于打印的页面。

回答

I guess it's true that using the table element for layout has little to do with tabular data. So what? Does my boss care? Do my users care?

Google和其他自动化系统确实很在乎，它们在许多情况下同样重要。对于非智能系统而言，语义代码更易于解析和处理。

回答

看到这个重复的问题。

我们忘记的一项是可访问性。例如，如果我们需要使用屏幕阅读器，则基于表的布局也不会翻译。如果我们确实为政府工作，则可能需要支持可访问的浏览器，例如屏幕阅读器。

我还认为我们低估了我们在问题中提到的某些事情的影响。例如，如果我们既是设计者又是程序员，那么我们可能对它如何很好地将演示文稿与内容分隔开来并不完全了解。但是，一旦进入一家商店，他们将扮演两个不同的角色，优势就会变得更加明显。

如果我们知道自己在做什么并且拥有好的工具，那么CSS确实比布局表具有明显的优势。尽管每个项目本身可能无法证明放弃表格是合理的，但总的来说值得这样做。

回答

必须与一个网站合作，该网站涉及由某个应用程序生成的6层嵌套表，并使其生成无效的HTML，实际上，纠正它的微小更改需要花费3个小时的工作。

当然这是边缘情况，但是基于表的设计是无法维护的。如果使用css，则会将样式分开，因此在修复HTML时，我们不必担心会打断。

另外，使用JavaScript尝试一下。将单个表格单元格从一个位置移动到另一张桌子的另一位置。在div / span只能复制粘贴的情况下执行起来比较复杂。

"我的老板在乎吗"

如果我是你的老板。你会在意的。 ;)如果我们珍视自己的生活。

回答

我想补充一点，基于div的布局更易于维护，发展和重构。只需对CSS进行一些更改即可对元素进行重新排序，即可完成。根据我的经验，重新设计使用表格的布局是一场噩梦(如果有嵌套表格，则更多)。

从语义的角度来看，代码也具有含义。

回答

内容和布局之间的分离还使我们可以更轻松地为站点生成易于打印的布局或者只是不同的外观(样式)，而无需创建不同的html文件。某些浏览器(如Firefox)甚至支持从视图菜单中选择样式表。

而且我确实认为维护无表布局更容易。我们不必担心行跨度，列跨度等。我们只需创建一些容器div并将内容放置在需要的位置即可。那就是说，我认为它也更具可读性(<div id =" sidebar">与<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 Zen Garden。如果我们告诉我我们可以轻松地对基于表的布局执行相同操作(请记住HTML不变)，那么请务必使用表进行布局。

其他两个重要的事情是可访问性和SEO。

两者都关心按什么顺序显示信息。如果基于表的布局将导航放置在页面上第二个嵌套表的第二行的第三个单元格中，则无法轻松在页面顶部显示导航。

因此，答案是可维护性，可访问性和SEO。

别偷懒即使学习起来有些困难，也要以正确和正确的方式做事。

回答

CSS布局通常在可访问性方面要好得多，只要内容按自然顺序排列且没有样式表就有意义。不仅屏幕阅读器在使用基于表格的布局时会遇到困难：它们还会使移动浏览器更难正确显示页面。

另外，使用基于div的布局，我们可以轻松地通过打印样式表完成一些很酷的事情，例如从打印的页面中排除页眉，页脚和导航，我认为用表格来做到这一点是不可能的，或者至少要困难得多基于布局。

如果我们怀疑使用div比使用表格更容易从布局中分离内容，请查看CSS Zen Garden中基于div的HTML，了解如何更改样式表可以极大地更改布局，并考虑是否可以如果HTML是基于表格的，则可以实现相同的各种布局...如果我们基于表格的布局，则不太可能使用CSS控制单元格中的所有间距和填充(如果我们使用几乎可以肯定，首先发现使用浮动div等更容易)。在不使用CSS来控制所有内容的情况下，并且由于表指定了HTML中事物从左到右和从上到下的顺序，因此表往往意味着布局在HTML中变得非常固定。

实际上，我认为要完全更改基于div和CSS的设计的布局而不改变div是非常困难的。但是，使用基于div和CSS的布局，可以轻松地调整各个块之间的间距及其相对大小之类的内容。

回答

It's good to separate content from layout

  But this is a fallacious argument; Cliche Thinking

这是一个谬误的论点，因为HTML表是布局！内容是表中的数据，表示是表本身。这就是有时将CSS与HTML分开可能非常困难的原因。我们不是要从演示文稿中分离内容，而是要从演示文稿中分离演示文稿！一堆嵌套的div与表没有什么不同，只是一组不同的标签。

将HTML与CSS分离的另一个问题是，它们需要彼此熟悉的知识，我们实际上无法完全将它们分离。无论我们做什么，HTML中的标记布局都与CSS文件紧密结合在一起。

我认为table vs divs取决于应用程序需求。

在工作中开发的应用程序中，我们需要页面布局，其中的各个部分将根据其内容动态调整大小。我花了几天时间试图使它与CSS和DIV跨浏览器一起使用，这真是一场噩梦。我们切换到表格，一切都正常了。

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

回答

DIV中没有任何论据值得我支持。

我会说：如果鞋子合适，穿上它。

值得注意的是，即使不是不可能，也很难找到一种很好的DIV + CSS方法来在两三列中呈现内容，这在所有浏览器上都是一致的，并且仍然按照我的意图进行。

这使大多数布局中的表都达到了某种平衡，尽管我对使用它们感到内((不明白为什么，人们只是说这很不好，所以我还是要听它们)，最后，务实的观点是对我来说，使用TABLES更加容易和快捷。我没有按小时付费，所以桌子对我来说更便宜。

回答

这是我的程序员从类似线程得到的答案

语义学101

首先看一下这段代码，然后思考这里出了什么问题...

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

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

当然，问题在于自行车不是汽车。对于自行车实例，汽车类是不合适的类。该代码没有错误，但是在语义上是错误的。它对程序员的反映很差。

语义学102

现在将此应用于文档标记。如果文档需要显示表格数据，则适当的标签应为<table>。但是，如果将导航放置在表中，那么我们会滥用<table>元素的预期用途。在第二种情况下，我们没有呈现表格数据-我们正在(mis)使用<table>元素来实现呈现目标。

结论

访客会注意到吗？不，你的老板在乎吗？可能是。我们有时会像程序员一样偷工减料吗？当然。但是我们应该吗？不。如果我们使用语义标记，谁会受益？我们以及专业声誉。现在去做正确的事。

回答

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

因此，一个旨在展示将设计保持在内容之外的优势的网站现在经常承诺将内容放入设计中。 (如果要更改HTML文件中的节标题，则显示的节标题不会更改)。

这仅表明，即使是那些提倡严格的DIV和CSS信仰的人，也无法遵循自己的规则。我们可以以此为指导来密切关注他们。

回答

• 508合规性-屏幕阅读器可以理解标记的能力。
• 等待渲染-表直到到达</ table>元素的末尾时，才在浏览器中渲染。

回答

div和CSS定位使设计更加灵活，从而使网页的修改和模板化变得更加容易。

就是说，如果我们对灵活性不感兴趣，那么使用表而不是使用CSS变形为表的某些div绝对容易得多，而且更快。我倾向于在创建设计时使用表格，只是为了使其看起来更快一点。

回答

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

Div并不是在替换表，它们在将内容分为相关内容(，)块中有自己的用途。如果我们没有技能并且依赖表，则通常必须将内容分成单元格才能获得所需的布局，但是使用语义标记时，我们无需触摸标记即可实现呈现。当生成标记而不是静态页面时，这确实很重要。

开发人员需要停止提供暗示布局的标记，以便我们中那些确实具有表达内容技能的人可以继续我们的工作，并且开发人员不必在演示文稿需要更改时回到他们的代码进行更改。

回答

由于创建布局所需的代码量，使用表布局的工具可能会变得异常繁重。 SAP的Netweaver门户默认情况下使用TABLE来布局其页面。

在我目前的工作中，生产SAP门户有一个主页，其HTML超过6万，深达7个表，是该页面中的3倍。再加上Javascript，其中有16个iframe的误用，其中包含类似表格的问题，CSS太重，等等，页面的大小超过5MB。

花时间降低页面权重，以便我们可以利用带宽与用户进行互动活动是值得的。

回答

布局灵活性
想象一下，我们正在制作一个包含大量缩略图的页面。
DIV：
如果将每个缩略图放入DIV中，则向左浮动，也许其中有10个适合一行。使窗口变窄，BAM连续为6个或者2个，或者可以容纳许多。
桌子：
我们必须明确地说出连续多少个单元格。如果窗口太窄，则用户必须水平滚动。

可维护性
与上述情况相同。现在，我们要将三个缩略图添加到第三行。
DIV：
添加它们。布局将自动调整。
桌子：
将新单元格粘贴到第三行。糟糕！现在那里有太多物品。从该行切一些，然后放在第四行。现在那里有太多物品。从该行中剪掉一些...(等)
(当然，如果我们使用服务器端脚本生成行和单元格，则可能不会有问题。)

回答

我曾经学过一个表可以立即加载，换句话说，当连接速度很慢时，该表所在的空间将一直为空白，直到整个表被加载为止；另一方面，一个div则与数据一样快地上下加载以及是否已经完成。

回答

如果我们在这种情况下支持桌面角度，请找到一个带有桌子的站点，然后让自己的屏幕阅读器脱离屏幕阅读器并关闭显示器。

然后使用一个语义上正确的div布局站点进行尝试。

我们会看到差异。

如果表中的数据采用表格形式而不是布局页面，则表不是邪恶的。

回答

值得弄清楚CSS和div，以便在页面布局的侧边栏之前加载和呈现中心内容列。但是，如果我们要使用浮动div来使徽标与一些赞助商文字垂直对齐，则只需使用表格并继续前进即可。禅宗花园宗教并没有带来太大的收益。

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

依赖于编码标准以"将内容与表示分离"的应用程序的更改日志将显示出垂直竖井之间并行变化的模式。如果对"内容"的更改总是伴随着对"表示"的更改，那么分区的成功程度如何？

如果我们确实想高效地对代码进行分区，请使用Subversion并查看更改日志。然后使用最简单的编码技术-div，表，JavaScript，包括，函数，对象，延续等-来构造应用程序，以使更改以简单舒适的方式适应。

回答

一张桌子的布局不会那么糟糕。但是大多数情况下，仅一张桌子就无法获得所需的布局。很快，我们将有2或者3个嵌套表。这变得非常麻烦。

• 它很难阅读。这不符合意见。只有更多的嵌套标签，上面没有识别标记。
• 将内容与演示文稿分开是一件好事，因为它使我们可以专注于正在做的事情。将两者混合会导致难以阅读的pages肿页面。
• CSS for styles允许浏览器缓存文件，并且后续请求要快得多。这是巨大的。
• 表格将我们锁​​定在设计中。当然，并不是每个人都需要CSS Zen Garden的灵活性，但是我从来没有在一个不需要在此四处更改设计的网站上工作过。使用CSS要容易得多。
• 表格很难样式化。我们对它们没有太多的灵活性(即，我们仍然需要添加HTML属性以完全控制表格的样式)

我大概有四年没有用过表格了。我没有回头。

我真的很建议阅读Andy Budd的CSS Mastery。这是梦幻般的。

图片位于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变慢)。

由于每个div是一个单独的元素，因此所有浏览器都更快地渲染css，因此可以在用户阅读时加载屏幕。 (用于海量数据集等)。在该实例中，我甚至使用css代替表，甚至不处理布局。

直到找到最后一个" /表"，嵌套表(单元格内的表等)才会呈现到浏览器窗口。更糟糕的是，定义不正确的表有时甚至无法渲染！否则，事情就会变得不正常。 (不能与" TD"等正确合并)

我将表用于大多数事情，但是当涉及到大数据以及希望为最终用户快速渲染屏幕的需求时，我会尽力利用CSS所提供的功能。

回答

我认为那条船已经航行了。如果我们查看行业的发展方向，我们会发现CSS和开放标准是该讨论的赢家。反过来，这意味着对于大多数html工作，除了表单之外，设计人员将使用div而不是表格。我很难，因为我不是CSS专家，但事实就是这样。

回答

我确实认为这是一个与普遍问题有关的问题。 HTML诞生时，没有人能预见到它的广泛使用。另一项技术在其自身成功的推动下几乎崩溃了。当用绿色文本终端在vi中用HTML编写HTML页面时，只需使用TABLE即可向页面的访问者展示数据，而大多数数据是以表格形式显示的。

我们都知道事情是如何演变的。 TABLEs相对较不流行，但是有很多理由偏爱基于DIV和CSS的布局(可访问性不是最后一种)。当然，我不能编写CSS来挽救生命：-)，而且我认为图形设计专家应该总是在手边。

就是说...即使在现代网站中，很多数据也应显示在表格中。

回答

当我们需要确保元素需要保留在布局中的特定物理关系中时，请使用表。对于数据而言，表通常是最好的布局元素，因为我们不希望列以一种特殊的方式包装并混淆关联。

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

灵活的CSS布局非常适合适用于移动设备和大屏幕以及打印和其他显示类型的内容，但是有时，内容仅需要以非常特定的方式显示，并且如果这需要屏幕阅读器无法轻松访问，这很可能是有道理的。

回答

我发现即使有最佳计划的div也会在几个方面出现缺陷。例如。 div没有办法让底部的栏始终位于浏览器的底部，即使其余内容没有到达浏览器的底部也是如此。而且，我们不能做得比三列更好，并且不能使列根据其内容的宽度而增长和收缩。最后，我们尝试首先使用div。但是，我们不会基于某些宗教内容和布局理想来限制我们的html设计。

回答

我将一遍又一遍地研究论点，并尝试显示其中的错误。

It's good to separate content from layout
  But this is a fallacious argument; Cliché Thinking.

它根本不是谬误的，因为HTML是故意设计的。元素的滥用可能不是完全没有问题的(毕竟，其他语言也已经开发出新的习语)，但是可能的负面影响必须加以抵消。另外，即使今天没有反对滥用<table>元素的论点，也可能由于浏览器供应商对该元素应用特殊对待的方式而出现。毕竟，他们知道<table>元素仅用于表格数据，并且可能会使用此事实来改进呈现引擎，从而在过程中巧妙地更改了<table>的行为，从而打破了以前的情况被滥用。

So what? Does my boss care? Do my users care?

要看。你的老板是尖尖的头发吗？然后他可能不在乎。如果她有能力，那么她会在意的，因为用户会。

Perhaps me or my fellow developers who have to maintain a web page care... Is a table less maintainable? I think using a table is easier than using divs and css.

大多数专业的Web开发人员似乎反对我们[需要引用]。实际上，这些表的维护性较差，这是显而易见的。使用表格进行布局意味着更改公司布局实际上意味着更改每个页面。这可能非常昂贵。另一方面，明智地将语义上有意义的HTML与CSS结合使用可能会将此类更改限制在CSS和所使用的图片中。

By the way... why is using a div or a span good separation of content from layout and a table not? Getting a good layout with only divs often requires a lot of nested divs.

深度嵌套的<div>是一种反模式，就像表布局一样。优秀的网页设计师不需要很多。另一方面，即使这样的深层div也没有很多表格布局问题。实际上，它们甚至可以通过在逻辑上将内容分成几部分来为语义结构做出贡献。

Readability of the code
  I think it's the other way around. Most people understand html, little understand css. It's simpler.

大多数人都没关系。专业很重要。对于专业人士而言，表格布局比HTML + CSS会产生更多的问题。这就像说我不应该使用GVim或者Emacs，因为记事本对大多数人来说更简单。否则我不应该使用LaTeX，因为MS Word对大多数人来说更简单。

It's better for SEO not to use tables

我不知道这是否正确，也不会将其用作参数，但这是合乎逻辑的。搜索引擎搜索相关数据。虽然表格数据当然可能是相关的，但用户搜索的内容很少。用户搜索页面标题或者类似突出位置中使用的术语。因此，将表格内容从过滤中排除，从而将处理时间(和成本！)大大减少是合乎逻辑的。

Tables are slower.
  An extra tbody element has to be inserted. This is peanuts for modern web browsers.

多余的元素与表变慢无关。另一方面，表的布局算法要困难得多，浏览器通常必须等待整个表加载后才能开始对内容进行布局。此外，无法缓存布局(可以轻松缓存CSS)。所有这些都已经在前面提到过了。

Show me some benchmarks where the use of a table significantly slows down a page.

不幸的是，我没有任何基准数据。我本人会对它感兴趣，因为这种说法缺乏一定的科学严谨性是正确的。

Most web sites that need an upgrade need new content (html) as well. Scenarios where a new version of a web site only needs a new css file are not very likely.

一点也不。我曾研究过几种情况，其中通过将内容和设计分离，简化了设计更改。通常仍然需要更改一些HTML代码，但是更改总是会局限得多。此外，有时必须动态进行设计更改。考虑模板引擎，例如WordPress博客系统使用的模板引擎。表布局实际上会杀死该系统。我曾为商业软件处理过类似案例。能够更改设计而不更改HTML代码是业务需求之一。

另一件事。表格布局使网站的自动解析(屏幕抓取)变得更加困难。这听起来很琐碎，因为毕竟是谁做的？我自己感到惊讶。如果相关服务没有提供WebService替代品来访问其数据，则屏幕抓取将大有帮助。我在生物信息学领域工作，这是一个可悲的现实。现代Web技术和WebService尚未普及到大多数开发人员，并且通常，屏幕抓取是使获取数据过程自动化的唯一方法。难怪许多生物学家仍然手动执行此类任务。适用于数千个数据集。

回答

用作纯布局的表确实会带来一些可访问性问题(我听说过)。但我知道这里要问的是，我们通过使用表格来确保网页上某些内容的正确对齐会以某种方式破坏网络。

我听过有人争辩说，事实上FORM标签和输入是数据，应该允许它们进入表。

关于使用表来确保一些元素正确对齐的争论导致代码的这种大量增加，倾向于包含单个DIV如何满足其所有需求的示例。他们并不总是包括他们必须为IE5，IE5.5，IE6，IE7编写的10行CSS和特殊的浏览器hack。

我认为仍然需要在设计中使用平衡。表格在工具箱中，只需记住它们的用途即可。

回答

我尝试尽可能避免使用TABLE，但是当我们设计复杂的表单时，将多种控件类型和不同标题位置与非常严格的控件组合在一起，则使用DIV并不可靠，或者通常几乎是不可能的。

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

因为表单的显示是动态的(某些部分的显示是基于案例状态或者用户权限的)，所以我们使用堆叠的DIV集，每个DIV包含一个逻辑分组的表单元素表。 TABLE的每一列都经过分类，因此可以由CSS控制。这样，我们可以关闭表单的不同部分，而不会出现表无法将行包装在DIV中的问题。

回答

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

另外，编辑使用表格制作的网站非常困难(我认为)

回答

这实际上不是关于" div是否比布局表更好"的问题。懂CSS的人可以使用"布局表"直接复制任何设计。真正的胜利是将HTML元素用于它们的用途。我们不将表用于非表格数据的原因与我们不存储整数的原因相同，因为将字符串用于表目的用途时，字符串技术更容易工作。如果有必要使用表格进行布局(由于1990年代初的浏览器缺点)，现在肯定不是。

回答

当然，OP有点麻烦，争论似乎这么一周，很容易反驳。

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

如果通过服务器应用程序生成的表实现布局，则新布局意味着更改应用程序，重新构建和重新部署应用程序(仅更改为css文件)。

另外，可访问性。用于布局的表格使网站无法访问，因此请不要使用它们。毫无疑问，更不用说违法了。

回答

我认为没有人会在乎网站表现良好且运行迅速时如何设计/实施。

我在HTML标记中同时使用了"表格"和" div" /" span"标记。

让我给我们几个论点，为什么选择div：

• 对于一个表，我们必须至少写入3个标签(table，tr，td，thead，tbody)，为实现良好的设计，有时我们会嵌套很多表
• 我喜欢页面上的组件。我不知道如何确切解释，但会尝试。假设我们需要一个徽标，并且必须将其仅一小部分放在下一页内容上。使用表格，我们必须剪切2张图像并将其放入2个不同的TD中。使用DIV，我们可以根据需要使用简单的CSS进行排列。我们最喜欢哪种解决方案？
• 当超过3个嵌套表用于执行某项操作时，我正在考虑使用DIV重新设计它

但是我仍在使用表格进行以下操作：

• 表格数据
• 自我扩展的内容
• 快速解决方案(原型)，因为每个浏览器上的DIV框模型都不同，因为许多生成器正在使用表等

回答

使用DIV，我们可以轻松切换内容。例如，我们可以这样做：

Menu | Content

Content | Menu

Menu
----
Content

在CSS(而不是HTML)中更改它很容易。我们还可以提供几种样式(右手，左手，小屏幕专用)。

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

另一个好处是，即使在视觉上以其他方式显示内容，内容在代码中也始终是相同的顺序(首先显示菜单，之后显示内容)。

回答

通常，表并不比CSS更容易或者更可维护。但是，存在一些特定的布局问题，其中表格确实是最简单，最灵活的解决方案。

显然，在表示性标记和CSS支持相同设计的情况下，CSS显然是更可取的，在他们的头脑中没有人会认为font-tags比在CSS中指定排版更好，因为CSS与font'具有相同的功能-标签，但使用的方式更简洁。

但是，表的问题基本上是Microsoft Internet Explorer不支持CSS中的表布局模型。因此，表和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，并在应该由CMS项目中的客户使用的模板中使用elementID CSS设置样式。这就是所见即所得在线编辑器的重点。我们正在同时控制内容和布局！在这种情况下，根本没有任何分离。在某些外部样式表中定位和设置样式的Divs不利于所见即所得编辑的整个思想。可以看到表，插入了行，合并了单元格等等。祝我们在div上尝试使用，不会让用户感到沮丧。

回答

简短的答案：使用表格很难设计可维护的网站，而使用标准方法则很容易。

网站不是表格，它是相互交互的组件的集合。将其描述为表格是没有意义的。

回答

One example: you want to center the
  main content area of a page, but in
  order to contain the floats inside it,
  it needs to be floated. There is no
  "float: center" in CSS.

这不是将浮标"包含"在居中元素中的唯一方法。因此，根本不是一个很好的论点！

在某种程度上，这是错误的前提，即" divs vs table"。

将页面快速脏乱地分为三列？坦白讲，表格更容易。但是没有专业人士再将它们用于布局，因为它们将页面元素的位置锁定在页面中。

真正的论点是"由CSS完成定位(希望在远程文件中)"，而不是"由HTML在页面中完成定位"。当然每个人都能看到前者相对于后者的好处吗？

• 大小-如果页面布局在HTML中，则无法在页面中进行缓存，因此必须在每个页面上重复进行。如果布局是在缓存的CSS文件中而不是在页面中，则将节省大量带宽。
• 多个开发人员可以同时在同一个页面上工作-我在处理HTML，其他人在处理CSS。不需要存储库，没有覆盖，文件锁定等问题。
• 进行更改更容易-在不同的浏览器中布局会出现问题，但是我们只需要修复一个文件CSS文件就可以解决它们。
• 辅助功能，如前所述。表格假定二维布局适用于所有人。这不是某些用户查看内容的方式，也不是Google查看内容的方式。

考虑一下：

[ 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和Orca Linux版)。

为此，最好将表格数据(即具有逻辑意义的数据以二维或者二维方式排序，并带有某种标题)放置在表中，并使用divs管理页面上内容的布局。 (考虑"表格数据"的另一种方法是尝试以图形形式绘制它……如果不能，则可能不能最好地在表格中表示)

最后，在基于表的布局中，为了实现对页面上元素位置的细粒度控制，经常使用高度嵌套的表。这有两个效果：1.)增加每个页面的代码大小由于表经常使用导航和通用结构，因此对于每个请求，网络上都会发送相同的代码，而基于div / css的布局会将css文件拖到一次，然后使用较少的冗长div。 2.)高度嵌套的表需要更长的时间供客户端的浏览器呈现，从而导致加载时间稍慢。

在这两种情况下，"最后一英里"带宽的增加以及速度更快的个人计算机都可以缓解这些因素，但是尽管如此，对于许多站点，它们仍然是存在的问题。

就像其他人所说的那样，考虑到所有这些因素，表更容易使用，因为它们更加面向网格，因此无需进行任何思考。如果所讨论的站点预计不会存在很长时间，或者不会得到维护，则可以选择最简单的方法，因为它可能是最具成本效益的。但是，如果预期的用户群可能包括相当一部分的残障人士，或者如果该站点将由其他人长时间维护，则花一些时间在前面以简洁，可访问的方式进行操作可能最终会获得更大的回报。

回答

我不得不用这两种方式来做网站，再加上用表格，div和样式来制作的可怕的"混合"布局：Div / CSS轻松胜出。

我们必须立即将div嵌套三层，以匹配仅一个表单元格的代码权重。该效果与嵌套表成比例。

我还希望更改布局，而不是对网站中的每个页面进行更改。

我可以完全控制divs / css演示的各个方面。表格以令人难以置信的方式弄乱了，尤其是在IE(我从未选择不支持的浏览器)中。

我维护或者重新设计divs / 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就很棒了，但坦率地说，流体的页眉/页脚和三个流体柱是div的总痛苦。 Divs不是为流动性而设计的，那么为什么要使用它们呢？

请注意，此方法将使我们在链接文本上100％符合CSS

回答

1：是的，用户确实在乎。如果他们使用屏幕阅读器，它将丢失。如果我使用任何其他尝试从页面中提取信息的工具，则遇到未用于表示表格数据的表将产生误导。

div或者span可以用于分隔内容，因为这正是这些元素的含义。当我(搜索引擎，屏幕阅读器或者其他任何东西)遇到表格元素时，我们希望这表示"以下是表格中表示的表格数据"。遇到div时，我们期望"这是用于将我的内容划分为单独的部分或者区域的元素。

2：可读性：错误。如果所有演示文稿代码都在CSS中，那么我可以阅读html并理解页面的内容。或者，我可以阅读CSS并理解演示文稿。如果html中的所有内容都杂乱无章，我必须在脑海中剔除所有与演示文稿相关的部分，然后才能看到内容是什么，内容是什么。
而且，我不敢遇到一个不了解CSS的Web开发人员，所以我真的不认为这是个问题。

3：表格比较慢：是的，确实如此。原因很简单：必须完全解析表，包括表的内容，然后才能呈现它们。可以在遇到div时呈现它，即使在解析其内容之前也是如此。这意味着div将在页面加载完成之前显示。

然后还有一个好处，那就是表要脆弱得多，并且在不同的浏览器中并不会总是使用不同的字体和字体大小以及可能导致布局变化的所有其他因素来呈现相同的表。表格是一种很好的方法，可以确保网站在某些浏览器中偏离一两个像素，当用户更改字体大小或者以其他任何方式更改设置时，缩放比例不会很好。

当然，＃1是大问题。许多工具和应用程序都依赖于网页的语义。通常的示例是视障用户的屏幕阅读器。如果我们是网络开发人员，则会发现许多大公司可能会雇用我们在网站上工作，即使在这种情况下，也要求该网站可以访问。这意味着我们必须考虑html的语义。使用语义网，或者更有意义的是，使用微格式，rss阅读器和其他工具，页面内容不再仅通过浏览器进行查看。

回答

我的英语很抱歉，但这是另一个原因：

我在某个政府机构工作，不使用TABLE的第一原因是残疾人。他们使用机器来"翻译"网页。

问题是如果"翻译机"是由TABLE完成的，则无法读取该网站。为什么 ？因为TABLE用于DATAS。

实际上，如果我们使用TABLES，则必须为每个CELLS指定一些信息，以使残疾人知道他们在TABLE中的位置。假设我们有一张大桌子，并且必须缩放以仅在屏幕上看到1个单元格：我们必须知道我们所在的行/列。

因此，使用了DIV，残障人士可以简单地阅读文本，并且不必在不需要行/列的情况下获得一些奇怪的信息。

我也更喜欢使用TABLE来制作快速简便的模板，但是我现在已经习惯了CSS ...它功能强大，但是我们确实必须知道自己在做什么... :)

回答

几年前，我研究了屏幕阅读器和桌子的问题，并提出了与大多数开发人员所认为的相矛盾的信息：

http://www.webaim.org/techniques/tables/

"我们可能会听到一些可访问性倡导者说布局表是个坏主意，应该使用CSS布局技术。他们说的话是有道理的，但是说实话，使用表进行布局并不是最糟糕的事情。就可访问性而言，我们可以做这些事情。只要表设计时考虑了可访问性，各种残障人士都可以轻松访问表。

回答

数据：使用表。布局：使用样式。使用精简的浏览器，即Links 2或者Lynx，无需样式，仅使用简单的标记即可实现表格的最快渲染。

回答

这是一个备受争议的问题，这一事实证明了W3C无法预期将要尝试的布局设计的多样性。使用divs + css进行语义友好的布局是一个不错的主意，但是实现的细节是如此有缺陷，以至于它们实际上限制了创作自由。

我试图将我们公司的一个站点从桌子切换到div，这非常令人头疼，以至于我完全放弃了我投入到表中的工作时间。试图与我的div搏斗以获得对垂直对齐的控制权，使我陷入了重大的心理问题，只要争论不断，我就永远不会动摇。

人们必须经常想出复杂而丑陋的变通方法来实现简单的设计目标(例如垂直对齐)，这一事实强烈表明，这些规则还不够灵活。如果规范足够，那么为什么备受瞩目的站点(如SO)认为有必要使用表和其他变通办法来弯腰规则呢？

回答

Google对表中包含的文本内容的优先级非常低。我正在向当地一家慈善机构提供SEO建议。在检查他们的网站时，它使用表格来布局网站。查看每个页面，无论是我在Google搜索框中使用的页面中的单词还是单词组合，这些页面都不会出现在任何热门搜索页面中。 (但是，通过在搜索中指定站点，返回了页面。)
一页是按正常标准写的很好的副本，可以在搜索中产生良好的结果，但仍未出现在返回的搜索结果的第一页中。 (请注意，此文本在表格中。)
然后，我在div而不是表格的页面上发现了一段文本。我们在搜索引擎中输入了该div中的一些单词。
结果？它在搜索结果中排在第二。

回答

• 尝试合并/拆分深度为colspan / rowspan的10/20内容。我不得不不止一次地抑制与某人打架的本能。 [？！]
• 尝试更改源代码顺序而不更改可见顺序。 [SEO，可用性...]
• 我们正在查看的(非常简单)页面约为150K。我敢打赌，使用正确的CSS几乎可以减少一半。 [SEO(是的，SEO，请阅读最新的Google规范等)，性能，...]
• 尝试制作可以在任何宽度下工作的迭代器模板。
• 在这种基于表的SO介质中对问题的讨论可能会导致奇异性并破坏我们所有人

回答

CSS / DIV只是设计人员的工作，不是吗。我花了数百个小时来调试DIV / CSS问题，在Internet上搜索以使标记的某些部分与晦涩的浏览器配合使用，使我发疯。我们做了一点改动，整个布局就大错特错了。花费几个小时以这种方式移动3像素，然后再移动2像素，使它们全部对齐。对于我来说，这似乎是完全错误的。仅仅因为我们是一个纯粹主义者而做某事是"不正确的事情"，并不意味着我们应该在所有情况下都使用n级，尤其是如果它使生活轻松了1000倍。

因此，我最终决定纯粹是出于商业考虑，尽管我一直在尽量减少使用，但如果我预计20个小时的工作才能正确放置DIV，我会坚持下去。这是错误的，它使纯粹主义者感到不安，但在大多数情况下，它花费的时间更少且管理起来更便宜。然后，我可以专注于让应用程序按照客户的要求工作，而不是取悦纯粹主义者。毕竟，他们确实支付账单，而我对强制使用CSS / DIV的经理的论点我只是指出，客户也要支付他的薪水！

所有这些CSS / DIV参数出现的唯一原因是因为CSS的缺点，而且由于浏览器彼此不兼容，如果它们兼容，那么世界上一半的Web设计师都将失业。 。

当我们设计Windows窗体时，不要在布局控件后尝试移动控件，因此我觉得对于我们为什么要使用Web窗体来做到这一点有点奇怪。我根本无法理解这种逻辑。正确地开始布局，这是什么问题。我认为这是因为设计师喜欢挥霍创意，而应用程序开发人员则更关心实际使应用程序正常工作，创建业务对象，实施业务规则，确定客户数据之间如何相互关联，确保事物满足客户需求。我们知道的需求，例如现实世界中的东西。

不要误会我的意思，这两个参数都是有效的，但是请不要批评开发人员选择一种更简单，更合乎逻辑的方法来设计表单。与在div上使用表的正确语义相比，我们通常要担心的事情更重要。

在此讨论的基础上，我将一些现有的tds和trs转换为div。 45分钟的时间弄得一团糟，试图让所有东西彼此排成一排，我放弃了。 TD在10秒后返回，可立即在所有浏览器上运行，仅此而已。请尝试让我理解我们希望我以其他任何方式这样做的理由是什么！

回答

因为维护一个使用表的站点是很困难的，并且需要很多时间来编写代码。如果我们害怕浮动div，请参加其中的课程。它们并不难理解，它们的工作效率大约提高了100倍，而使痛苦减少了100万倍(除非我们不了解它们-但是，嘿，欢迎来到计算机世界)。

考虑使用表格进行布局的任何人最好不要期望我维护它。这是呈现网站的最粗暴的方式。谢天谢地，我们现在有一个更好的选择。我永远不会回去。

令人恐惧的是，有些人可能没有意识到使用现代工具创建网站所节省的时间和精力。