在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而不是表的良好参数非常感兴趣。


当前回答

我很抱歉我的英语不好,但还有一个原因:

我在一些政府机构工作,不使用TABLE的首要原因是残疾人。他们使用机器“翻译”网页。

问题是这个“翻译机器”不能阅读网站,如果它是由TABLE。为什么?因为TABLE是用于数据的。

事实上,如果你使用TABLES,你必须为每个cell指定一些信息,让残疾人知道他们在TABLE中的位置。想象一下,你有一个大表格,必须放大才能看到屏幕上的一个单元格:你必须知道你在哪一行/col。

因此,使用DIV,并且禁用可以简单地阅读文本,并且不会得到一些关于行/cols的奇怪信息,当它们不需要在那里时。

我也更喜欢TABLE来制作快速简单的模板,但我现在习惯了CSS…它很强大,但你真的必须知道你在做什么……:)

其他回答

I have found that even with the best planning divs come up short in several respects. For instance. there is no way with divs to have a bottom bar that always sits at the bottom of the browser, even when the rest of the content does not go to the bottom of the browser. Also, you cannot elegantly do anything better than three columns, and you cannot have columns that grow and shrink according the the width of their content. In the end, we try to use divs first. However, we will not limit our html designs based on some religious content vs layout ideal.

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.

一个例子:你想要居中 一个页面的主要内容区域,但在 为了把浮体装在里面, 它需要浮动。没有 CSS中的float: center。

这并不是在居中元素中“包含浮点数”的唯一方法。所以,这根本不是一个好的论点!

在某种程度上,“divs vs table”是一个错误的前提。

把一页快速地分成三列?说实话,表格更简单。但是没有专业人士将它们用于布局,因为它们将页面元素的位置锁定在页面中。

真正的争论是“由CSS完成的定位(最好是在远程文件中)”,而不是“在页面中由HTML完成的定位”。相对于后者,每个人都能看到前者的好处吗?

Size -- if your page layout is in the HTML, in the pages, it can't be cached, and it has to be repeated on every page. You will save enormous amounts of bandwidth if your layout is in a cached CSS file, not in the page. Multiple developers can work on the same page at the same time -- I work on the HTML, other guy works on the CSS. No repository needed, no problems with over-writing, file locking etc. Making changes is easier -- there will be problems with layout in different browsers, but you only have to fix one file, the CSS file, to sort them out. Accessibility, as mentioned a lot previously. Tables assume a two-dimensional layout works for everyone. That's not how some users view your content and it's not how Google views your content.

考虑一下:

[ picture ] [ picture ] [ picture ]
[ caption ] [ caption ] [ caption ]

表示包含6个单元格的表中的两行。能看到二维表格布局的人会在每张图片下看到标题。但是使用语音合成,或者PDA,以及搜索引擎蜘蛛,那是

picture picture picture caption caption caption

有了表格,这种关系就明显消失了。

div和CSS是否更适合在HTML页面上简单地布局矩形以在最短的时间内实现给定的设计?不,他们可能不是。但我不是在快速布局矩形来实现给定的设计。我想的是更大的前景。

根据我对表的了解,如果嵌套了太多的表,在呈现页面时浏览器会有很大的开销。

1 -浏览器必须等待呈现最终视图,直到整个表被加载。

2 - The algorithm to render the table is expensive and is not in a single go. The browser, as and when, gets the contents, will try to render calculating the content width and height. So, if you are having nested tables, say, the browser has received the first row and the 1st cell is having large amount of content and width and height not defined, it will calculate the width and will render the first row, In the mean while it gets the 2nd row will cell#2 having loads of content! It will now calculate the width for 2nd row cells.. What about the first ? It will calculate widths recursively. That's bad at client side. (To site an example) As a programmer, you'll optimize stuffs such as time to fetch data, optimized data structures and etc. You optimize things to complete on server side, say in2 secs, but end user in getting the final view in 8 secs. What is wrong here ? 1. May be network is slow! What if network is fine ? What is network is delivering the contents in next 1 sec ? Where is this extra 5 secs getting consumed ? Thing to worry about-- The browser might be taking lot of time in estimating and rendering the tables!

如何优化表? 如果你使用表格,我建议,总是定义单元格的宽度。这并不能保证浏览器会盲目地只取这个宽度,但会对浏览器决定初始宽度有很大的帮助。

但是,最后,div是CSS可以被浏览器缓存的好方法;而表没有缓存!

DOM操作在基于表的布局中是很困难的。

使用语义div:

$('#myawesomediv').click(function(){
    // Do awesome stuff
});

表:

$('table tr td table tr td table tr td.......').click(function(){
    // Cry self to sleep at night
});

当然,第二个例子有点愚蠢,您总是可以将id或类应用到表或td元素上,但这将增加语义值,这是表的支持者强烈反对的。