在HTML中,表格不应该用于布局,这似乎是普遍的观点。

Why?

我从来没有(老实说,很少)看到过支持这一点的有力论据。通常的答案是:

It's good to separate content from layoutBut this is a fallacious argument; Cliche Thinking. 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?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.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. Readability of the codeI think it's the other way around. Most people understand HTML, few understand CSS. It's better for SEO not to use tablesWhy? Can anybody show some evidence that it is? Or a statement from Google that tables are discouraged from an SEO perspective? Tables are slower.An extra tbody element has to be inserted. This is peanuts for modern web browsers. Show me some benchmarks where the use of a table significantly slows down a page. A layout overhaul is easier without tables, see css Zen Garden.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. Zen Garden is a nice web site, but a bit theoretical. Not to mention its misuse of CSS.

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


当前回答

有必要弄清楚CSS和div,以便在页面布局中,中央内容列在侧栏之前加载和呈现。但是,如果你正在努力使用浮动div来垂直对齐一个logo和一些赞助文本,那就使用这个表格,继续生活吧。禅宗花园宗教并没有带来多少价值。

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

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

如果您真的想高效地划分代码,请使用Subversion并检查更改日志。然后使用最简单的编码技术——divs、表、JavaScript、include、函数、对象、延续等等——来构建应用程序,以便以简单和舒适的方式进行更改。

其他回答

使用表格布局的工具可能会因为创建布局所需的大量代码而变得异常沉重。SAP的Netweaver Portal默认使用TABLE来布局页面。

在我目前的工作中,生产SAP门户有一个主页,它的HTML超过60K,有7个表那么深,在页面中有3次。再加上Javascript,误用了16个iframe,其中有类似的表格问题,CSS过重等,页面重量超过5MB。

花点时间降低页面重量,这样你就可以利用带宽与用户进行互动,这是值得的。

我曾经了解到,一个表是立即加载的,换句话说,当连接很慢的时候,表所在的空间保持空白,直到整个表被加载,另一方面,一个div加载从上到下的速度与数据到达的速度一样快,不管它是否已经完成。

当我使用CSS设计我的布局时,我通常给每个主要部分都有自己的根(主体级别)div,并使用相对/绝对定位将其置于适当的位置。这比表更灵活一些,因为我不局限于可以用行和列表示的排列。

此外,如果我决定我想要重新安排布局(说我想要导航栏现在在右边),我可以简单地去改变一个地方(CSS文件)的元素位置,HTML不需要改变。如果我对表执行此操作,我将不得不进入并找到信息,并进行大量属性修改和复制粘贴以获得相同的效果。

事实上,使用CSS,我甚至可以让我的用户选择他们想要的布局如何工作。只要内容区域的一般大小不改变,我完全可以使用一些PHP脚本来根据用户的偏好输出CSS,并允许他们根据自己的喜好重新排列站点。同样,对于表也是可以的,但是维护起来要困难得多。

最后,CSS提供了一个表永远无法提供的主要好处:基于显示设备重新格式化内容的能力。CSS允许我在打印机上使用与显示器上完全不同的样式集(包括位置、格式等)。这也可以扩展到其他媒体,一个很好的例子是Opera Show,它允许一个设计巧妙(非常标准)的CSS增强页面被视为幻灯片显示。

因此,最终,灵活性和管理才是真正的赢家。一般来说,CSS允许你对布局做更多的事情。基于表的布局在技术上没有什么不标准的,但为什么要限制自己呢?

In the past, screen readers and other accessibility software had a difficult time handling tables in an efficient fashion. To some extent, this became handled in screen readers by the reader switching between a "table" mode and a "layout" mode based on what it saw inside the table. This was often wrong, and so the users had to manually switch the mode when navigating through tables. In any case, the large, often highly nested tables were, and to a large extent, are still very difficult to navigate through using a screen reader.

The same is true when divs or other block-level elements are used to recreate tables and are highly nested. The purpose of divs is to be used as a fomating and layout element, and as such, are intended used to hold similar information, and lay it out on the screen for visual users. When a screen reader encounters a page, it often ignores any layout information, both CSS based, as well as html attribute based(This isn't true for all screen readers, but for the most popular ones, like JAWS, Windows Eyes, and Orca for Linux it is).

为此,表格式数据,也就是逻辑上有意义的在二维或多维维度中排序的数据,具有某种标题,最好放在表中,并使用div来管理页面上内容的布局。(另一种思考“表格数据”的方式是尝试以图表形式绘制它……如果你不能,它可能不是最好的表示在一个表中)

Finally, with a table-based layout, in order to achieve a fine-grained control of the position of elements on the page, highly nested tables are often used. This has two effects: 1.) Increased code size for each page - Since navigation and common structure is often done with the tables, the same code is sent over the network for each request, whereas a div/css based layout pulls the css file over once, and then uses less wordy divs. 2.) Highly nested tables take much longer for the client's browser to render, leading to slightly slower load times.

在这两种情况下,“最后一英里”带宽的增加,以及更快的个人电脑缓解了这些因素,但它们仍然是许多网站存在的问题。

With all of this in mind, as others have said, tables are easier, because they are more grid-oriented, allowing for less thought. If the site in question is not expected to be around long, or will not be maintained, it might make sense to do what is easiest, because it might be the most cost effective. However, if the anticipated userbase might include a substantial portion of handicapped individuals, or if the site will be maintained by others for a long time, spending the time up front to do things in a concise, accessible way may payoff more in the end.

事实上,这是一个激烈争论的问题,这证明了W3C未能预见到将尝试的布局设计的多样性。使用divs+css进行语义友好的布局是一个很好的概念,但实现的细节有很大的缺陷,实际上限制了创作的自由。

我曾试图将我们公司的一个网站从餐桌切换到餐桌,这让我非常头疼,以至于我完全放弃了投入其中的工作时间,回到餐桌上。为了获得垂直对齐的控制,我试图与我的跳水手搏斗,这让我受到了重大的心理问题的诅咒,只要这场辩论继续下去,我就永远不会动摇。

人们必须经常想出复杂而丑陋的变通办法来实现简单的设计目标(比如垂直对齐),这一事实强烈地表明这些规则还不够灵活。如果规格已经足够了,那么为什么高调的网站(如SO)发现有必要使用表格和其他变通方法来改变规则呢?