代码臃肿：你至少需要写下<table><tr><td>这三个标签之后，才能开始真正的内容，另外，Table的各种标签中还包含了复杂的属性定义，而Div只需<div>一个标签。
页面渲染性能问题：浏览器需要将整个表格完全读完后才会开始渲染。
不利于搜索引擎优化：搜索引擎喜欢内容与修饰分开。
可访问性差：屏幕朗读软件和盲文浏览器无法很好地理解Table中的内容。
不够语义（Semantic）：我们需要语义的Web。
第1条：代码臃肿
首先，Table里面唯一无法用CSS定义的属性只有Cellspacing，Cellpadding几个，其它属性都可以并且应当使用CSS，这样，剩下的，就是<table><tr><td>和<div>的对决，我相信一个动辄几十K大小的网页，即使使用了几十个Table，因此多出来的代码也可以忽略不计，那些埋怨Table代码臃肿的人其实该检查自己的编码习惯，能将Table写得十分臃肿的人，写Div相比也未必会简洁到哪里。
第2条：页面渲染性能问题
我使用一台2004年的笔记本电脑，1.6G的CPU与1G内存，这种配置下，看不出Table布局和Div布局在页面渲染上有任何速度差别，其实这点差别即使有，相对网络本身的延迟也可以忽略。
第3条：不利于搜索引擎优化
如果你尽可能使用CSS而不是Table的属性，前面说了，产生的代码和Div的差别也不会很大，搜索引擎会歧视<table>标签吗，这种说法的依据我至今并没有找到。
第4条：可访问性差
这是Table固有的缺陷，不过多数Div+CSS的拥趸似乎并不是基于这个原因才排斥Table。
第5条：不够语义
语义Web的含义要深远得多，并不是仅仅在Table和Div上纠缠，即使W3C，也并没有规定Table只能用来显示表格数据，很多在Table的语义上进行纠缠的人，其实不妨再等等HTML5，那才是真正的语义。
本文的目的不是让你丢弃Div投身Table，相反，如果Div能满足你的设计需要，Div仍是首选，但没必要避讳Table，否则会走入另外一个极端。很多使用Div无法简单实现的设计，仍可以使用Table，当然，不管使用什么，都应该用CSS将内容与修饰分离。Div+CSS和Table+CSS都是合法的设计，谁更简单就用谁。根据我的经验，当你能预见你的内容的格式，对你即将加入的内容有能力完全控制其显示格式时，应当使用Div+CSS；当你即将加入的内容是不固定的，你无法预见其格式，如果不想让页面坍塌，使用Table+CSS是一种保险的做法。
