表格table和CSS.docVIP

表格table和CSS+DIV排版模式的优缺点比较 　　Div 成为幸运者一方面因为它天生就是 Box 的最佳原型，在语义上，Div 代表页面的一个区域，在外形上，它四四方方，更重要的是，它不像　　 　　或 那样事先已经被赋予特殊的语义（虽然它们也能用于 Box 模型）；另一方面，则出于人们对 Table 统治一个臃肿时代的憎恶，一个时代的结束，继任者都会努力抹去旧时代的痕迹，那些旧时代的象征或代表的命运多半如此，人们并不是简单地忘却它们，而是断然划清界限。　　 　　Table 的一切不公平待遇就此开始。为什么说不公平，W3C 不建议 Table 布局的时候，只说应使用 CSS 代替，这是什么意思，Table 不支持 CSS 吗？当然支持，而且，由于 Table 作为老牌的 HTML 对象，它的地位曾如此重要，任何浏览器都对 Table 提供了最完美的支持，包括 CSS 支持。当人们拥抱 Div 的时候，似乎忘记了 Table 也是 Box，而且是一个拥有多个内格的 Box，Table 作为一个整体，和 Div 在 Box 模型方面没有任何区别，而它的内格，除了 Margin 之外，仍然是一个 Box，内格不含 Margin 概念这是应该理解的。Div 很优秀这不必说，然而当人们说 Div + CSS 的时候，似乎暗示着 Table 无法 CSS，这是天大的误会。　　 　　Div 支持的所有 CSS 属性，Table 全部支持，事实上，在 Div 大红大紫之前，那些 Div 的早期采用者曾信心不足地表示，Table 能做到，Div 都能，而他们也为自己的话付出了代价，企图在 Div 中实现垂直居中的人明白我的意思，企图在 IE6 中不经 CSS Hack 而实现 100% Div 布局的人更明白我的意思。100% Height 问题，几个 Div 之间的宽度自适应问题，相信任何从事 Div + CSS 设计的人会遇到。Table 在这方面的优势并不是因为它本身多么优秀，而是因为它老牌，没有浏览器敢忽视，也因为它的特性原本如此，人们发明表格，是因为希望数据显示得整齐，就这么简单。然而，为什么 Table 后来背上那么多的恶名？Div 拥护者对 Table 的责难不外乎以下几条。　　 　　代码臃肿：你至少需要写下　　 　　　　　　这三个标签之后，才能开始真正的内容，另外，Table 的各种标签中还包含了复杂的属性定义，而 Div 只需　　 　　一个标签。　　 页面渲染性能问题：浏览器需要将整个表格完全读完后才会开始渲染。　　 不利于搜索引擎优化：搜索引擎喜欢内容与修饰分开。　　 可访问性差：屏幕朗读软件和盲文浏览器无法很好地理解 Table 中的内容。　　 不够语义（Semantic）：我们需要语义的 Web。　　 　　　　第1条：代码臃肿　　 　　首先，Table 里面唯一无法用 CSS 定义的属性只有 Cellspacing, Cellpadding 几个，其它属性都可以并且应当使用 CSS，这样，剩下的，就是　　 　　　　　　和　　 　　的对决，我相信一个动辄几十K大小的网页，即使使用了几十个 Table，因此多出来的代码也可以忽略不计，那些埋怨 Table 代码臃肿的人其实该检查自己的编码习惯，能将 Table 写得十分臃肿的人，写 Div 相比也未必会简洁到哪里。　　 　　　　第2条：页面渲染性能问题　　 　　我使用一台2004年的笔记本电脑，1.6G 的 CPU 与 1G 内存，这种配置下，看不出 Table 布局和 Div 布局在页面渲染上有任何速度差别，其实这点差别即使有，相对网络本身的延迟也可以忽略。　　 　　第3条：不利于搜索引擎优化　　 　　如果你尽可能使用 CSS 而不是 Table 的属性，前面说了，产生的代码和 Div 的差别也不会很大，搜索引擎会歧视　　 　　标签吗，这种说法的依据我至今并没有找到。　　 　　第4条：可访问性差　　 　　这是 Table 固有的缺陷，不过多数 Div + CSS 的拥趸似乎并不是基于这个原因才排斥 Table。　　 　　第5条：不够语义　　 　　语义 Web 的含义要深远得多，并不是仅仅在 Table 和 Div 上纠缠，即使 W3C，也并没有规定 Table 只能用来显示表格数据，很多在 Table 的语义上进行纠缠的人，其实不妨再等等 HTML 5，那才是真正的语义。　　 　　本文的目的不是让你丢弃 Div 投身 Table，相反，如果 Div 能满足你的设计需要，Div 仍是首选，但没必要避讳 Table，否则会走入另外一个极端。很多使用 Div 无法简单实现的设计