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


当前回答

我没有对DIVs有利的论据。

我会说:如果事实属实,那就接受吧。

值得注意的是,要找到一种好的DIV+CSS方法来在两列或三列中呈现内容,并且在所有浏览器上都是一致的,并且看起来仍然是我想要的方式,即使不是不可能,也是很困难的。

在我的大多数布局中,这让平衡感向表格倾斜了一点,尽管我对使用它们感到内疚(不知道为什么,人们只是说它不好,所以我试着听他们的),最后,务实的观点是,对我来说,使用表格更容易、更快。我不是按小时计酬的,所以桌子对我来说比较便宜。

其他回答

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

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可以被浏览器缓存的好方法;而表没有缓存!

几年前,我研究了屏幕阅读器和表格的问题,得出了与大多数开发者想法相矛盾的信息:

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

你可能会听到一些易访问性倡导者说布局表是一个坏主意,应该使用CSS布局技术。他们说的有道理,但是,老实说,在可访问性方面,使用表格进行布局并不是最糟糕的事情。只要桌子在设计时考虑到可访问性,各种残疾的人都可以轻松地使用桌子。”

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

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

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

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

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

我尽量避免使用TABLEs,但是当我们设计复杂的表单,混合了多种控件类型和不同的标题位置,并对分组进行了非常严格的控制时,使用DIVs是不可靠的,甚至几乎是不可能的。

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

因为表单的表示是动态的(其中某些部分的显示是基于案例的状态或用户的权限),所以我们使用一组堆叠的div,每个div包含一个由逻辑分组的表单元素组成的TABLE。TABLE的每一列都被分类,这样CSS就可以控制它们。这样,我们就可以关闭表单的不同部分,而不会出现在div中不是表来换行的问题。

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

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

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