为什么不使用表格在HTML中进行布局？[关闭]

人们普遍认为，不应在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是故意设计的。元素的滥用可能不是完全没有问题的（毕竟，其他语言也开发了新的习惯用法），但必须抵消可能的负面影响。此外，即使<table>今天没有反对滥用该元素的争论，但由于浏览器供应商对元素进行特殊处理的方式可能还会出现明天。毕竟，他们知道“ <table>元素仅用于表格数据”，并且可能会使用此事实来改进渲染引擎，在此过程中巧妙地更改<table>s的行为，从而打破了以前被滥用的情况。

所以呢？我的老板在乎吗？我的用户在乎吗？

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

也许是我或我的同伴开发人员，他们必须维护网页……表的维护性较差吗？我认为使用表格比使用div和CSS更容易。

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

顺便说一句...为什么使用div或span不能很好地将内容与布局和表格分开？仅使用div获得良好的布局通常需要大量嵌套的div。

深度嵌套<div>s和表布局一样都是反模式。优秀的网页设计师不需要很多。另一方面，即使是这样嵌套较深的div也没有很多表布局问题。实际上，它们甚至可以通过将内容按逻辑划分为一个语义结构。

我认为代码的可读性是相反的。大多数人了解html，很少了解css。更简单。

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

SEO最好不要使用表格

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

表比较慢。必须插入一个额外的tbody元素。这是用于现代Web浏览器的花生。

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

向我展示一些基准测试，在这些基准测试中使用表会大大降低页面速度。

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

大多数需要升级的网站也需要新的内容（html）。新版本的网站仅需要新的CSS文件的情况不太可能发生。

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

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

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

语义学101

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

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

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

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

语义学102

现在将其应用于文档标记。如果您的文档需要显示表格数据，则相应的标签为<table>。但是，如果将导航放置到表中，则表示您滥用了<table>元素的预期用途。在第二种情况下，您不是在显示表格数据，而是（错误地）使用该<table>元素来实现表示性目标。

结论

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

明显答案：请参阅 CSS Zen Garden。如果您告诉我您可以轻松地对基于表的布局进行相同的操作（请记住-HTML不变），那么请务必使用表进行布局。

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

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

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

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

看到这个重复的问题。

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

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

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

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

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

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

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

一张桌子的布局不会那么糟糕。但是大多数情况下，仅一张桌子就无法获得所需的布局。很快，您将有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

将内容与布局分开是很好的，
但这是一个谬误的论点。陈词滥调

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

将HTML与CSS分离的另一个问题是它们需要彼此的深入了解-您确实无法将它们完全分离。无论您做什么，HTML中的标记布局都与CSS文件紧密结合在一起。

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

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

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

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秒后返回-在所有浏览器上均可正常运行-无需执行任何操作。请尝试让我理解-您希望我以其他任何方式这样做有什么可能的理由！

布局应该很容易。事实上，有文章介绍了如何在CSS中使用页眉和页脚实现动态三列布局，这表明它是一个较差的布局系统。当然，您可以使用它，但是实际上有数百篇有关如何执行此操作的文章。对于表格的类似布局，几乎没有此类文章，因为它显然是显而易见的。无论您对表说什么，而对CSS表示赞成，这一事实都无法解决所有问题：CSS中基本的三列布局通常称为“圣杯”。

如果那不能使您说出“ WTF”，那么您现在真的需要放下酷玩乐队。

我喜欢CSS。它提供了惊人的样式选项和一些很酷的定位工具，但作为布局引擎，它是不足的。需要某种类型的动态网格定位系统。在多个轴上对齐框的直接方法，无需先知道框的大小。如果您将其称为<table>或<gridlayout>或其他名称，我不会给您该死，但这是CSS所缺少的基本布局功能。

更大的问题是，由于不承认缺少某些功能，CSS狂热者一直在阻止CSS。如果CSS提供了像世界上其他所有布局引擎一样的体面的多轴网格定位，我将非常乐意停止使用表。（您确实意识到，除了W3C以外，每个人都已经用许多语言解决了许多问题，对吗？没有其他人否认此功能很有用。）

叹。足够的排气。继续前进，将头伸回到沙滩上。

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

如果为每个div分配名称，则也可以使用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>

我在基于表的布局中看到的唯一整洁的事实是，我对缩进过于狂热。我敢肯定，内容部分将有另外两个嵌入式表。

要考虑的另一件事：filesizes。我发现基于表的布局通常是其CSS布局的两倍。在我们的高速宽带上，这不是一个大问题，但是在那些使用拨号调制解调器的宽带上是这样。

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

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

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

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

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

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

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

此外，使用基于div的布局，您可以非常轻松地使用打印样式表来完成一些很酷的事情，例如从打印的页面中排除页眉，页脚和导航-我认为，使用基于表格的布局。

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

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

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

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

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

我想这是真的，使用表格元素进行布局与表格数据无关。所以呢？我的老板在乎吗？我的用户在乎吗？

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

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

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

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

“我的老板在乎吗”

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

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

可维护性
与上述情况相同。现在，您想在第三行中添加三个缩略图。
DIV：
将其添加。布局将自动调整。
表： 将新单元格粘贴到第三行。糟糕！现在那里有太多物品。从该行切一些，然后放在第四行。现在那里有太多物品。从该行中切出一些...（等）
（当然，如果您正在使用服务器端脚本生成这些行和单元格，那么这可能不会成为问题。）

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

另外，请不要忘记，表格在移动浏览器上的渲染效果不佳。当然，iPhone具有辅助功能浏览器，但每个人都没有iPhone。表格渲染对于现代浏览器而言可能是花生，但对于移动浏览器而言却是一大堆西瓜。

我个人发现许多人使用了太多<div>标签，但要适度使用，它可能非常干净且易于阅读。您提到，与表相比，人们阅读CSS更加困难。就“代码”而言可能是正确的；但是在阅读内容方面（视图>源代码），用样式表比使用表更容易理解结构。

看起来您只是习惯了表格，仅此而已。将布局放在表中会限制您仅使用该布局。使用CSS，您可以四处移动，看看http://csszengarden.com/ ，不，布局通常不需要很多嵌套的div。

由于没有用于布局的表格和适当的语义，HTML更加整洁，因此更易于阅读。为什么不能理解CSS的人应该尝试阅读它？而且，如果有人认为自己是Web开发人员，那么必须对CSS有良好的掌握。

SEO的优势在于能够将最重要的内容置于页面上方，并且具有更好的内容与标记比率。

http://www.hotdesign.com/seybold/

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

在表示性标记和CSS支持相同类型的设计的情况下，CSS显然是更可取的，他们中没有人会认为font-tags比CSS中指定版式更好，因为CSS具有与font-tags 相同的功能，但是在更干净的方法。

但是，表的问题基本上是Microsoft Internet Explorer不支持CSS中的表布局模型。因此，表和CSS的功能不相同。缺少的部分是表格的网格状行为，其中单元格的边缘在垂直和水平方向上对齐，而单元格仍在扩展以包含其内容。如果不对某些尺寸进行硬编码，那么在纯CSS中就很难实现这种行为，这会使设计变得僵化和脆弱（只要我们必须支持Internet Explorer-在其他浏览器中，使用即可轻松实现display:table-cell）。

因此，实际上不是要使用表还是CSS的问题，而是要认识到使用表可以使布局更灵活的特定情况的问题。

不使用表的最重要原因是可访问性。《 Web内容可访问性指南》（http://www.w3.org/TR/WCAG10/）再次使用表进行布局。如果您担心可访问性（在某些情况下，您可能会在法律上有义务遵守），即使表更简单，也应使用CSS。请注意，您始终可以使用CSS创建与表格相同的布局，这可能只需要做更多的工作。

我很惊讶地发现某些问题尚未解决，因此，除了早些时候提出的所有非常有效的观点之外，这是我的2美分：

.1。CSS和SEO：

a）CSS过去通过允许将内容放置在页面中的任何位置，对SEO产生非常重要的影响。几年前，搜索引擎非常重视“页面上”因素。页面顶部的内容比页面底部的内容与页面更相关。蜘蛛的“页面顶部”表示“代码的开头”。使用CSS，您可以在代码的开头组织关键字丰富的内容，并且仍然可以将其放置在页面中的任何位置。这仍然有些相关，但是页面因素对于页面排名越来越不重要。

b）当布局移到CSS上时，HTML页面变浅，因此对于搜索引擎蜘蛛来说加载速度更快。（蜘蛛程序不必费心下载外部CSS文件）。快速加载页面是包括Google在内的多个搜索引擎的重要排名考虑因素

c）SEO工作通常需要测试和更改，这对于基于CSS的布局要方便得多

.2。生成的内容：

与等效的CSS布局相比，以编程方式生成表要容易得多。

foreach ($comment as $key=>$value)
{
   echo "<tr><td>$key</td><td>$value</td></tr>";
}

生成表既简单又安全。它是独立的，可以很好地集成到任何模板中。要在CSS上执行相同的操作要困难得多，并且可能根本没有任何好处：难以在飞行中编辑CSS样式表，并且内联添加样式与使用表格没有区别（内容未与布局分开）。

此外，当生成表时，内容（在变量中）已经与布局（在代码中）分开，使其易于修改。

这就是为什么某些设计良好的网站（例如SO）仍然使用表格布局的原因之一。

当然，如果需要通过JavaScript对结果进行处理，则divs是值得的。

.3。快速转换测试

在确定对特定受众有用的内容时，能够以各种方式更改布局以找出获得最佳效果的方法很有用。基于CSS的布局使事情变得更加容易

.4。针对不同问题的不同解决方案

通常不要使用布局表，因为“所有人都知道divs和CSS”是解决之道。

但是，事实仍然是，与大多数CSS布局相比，表的创建速度更快，更易于理解并且更强大。（是的，CSS可能同样强大，但是在不同的浏览器和屏幕分辨率下通过网络快速浏览通常并不常见）

餐桌上有很多缺点，包括维护，缺乏灵活性……但不要让婴儿洗澡时再扔水。快速可靠的解决方案有很多专业用途。

前段时间，我不得不使用表重写干净简单的CSS布局，因为很大一部分用户将使用较旧版本的IE，但对CSS的支持确实很差

我一个人讨厌膝盖的反应，“哦，不！要摆放桌子！”

至于“它不是为了这个目的，因此您不应该这样使用”人群，这不是伪善吗？您如何看待要使大多数浏览器都能正常工作所需的所有CSS技巧？他们是为了这个目的吗？