*以下文字为搜集一些网站或论坛里面的文章，不代表本人观点，仅供参考。 南京网站建设 恒网========================================================

其实并不是div比table快，只是div有些优点会使它“快”过table。
1、div可以下载一个显示一个，而table要完整下载才能显示。
2、div可以用更少的div来排版。

原因主要在，table标记要解析到对应的才会显示，而div这里就不用！它用由上而上显示 出来！

    CSS＋DIV是网站标准（或称“WEB标准”）中常用的术语之一，通常为了说明与HTML网页设计语言中的表格（table）定位方式的区别，因为XHTML网站设计标准中，不再使用表格定位技术，而是采用css+div的方式实现各种定位。

    CSS＋DIV网站设计的优势

    首先，CSS的极大优势表现在简洁的代码，对于一个大型网站来说，可以节省大量带宽，而且众所周知，搜索引擎喜欢清洁的代码（其真正意义在于，增加了有效关键词占网页总代码的比重），因此使用CSS＋DIV的web标准制作的网站具有搜索引擎友好的一定优势。

    其次，CSS+DIV制作的网站使得网站改版相对简单，很多问题只需要改变CSS而不需要改动程序，从而降低了网站改版的成本。

    尽管CSS+DIV具有一定的优势，不过现阶段CSS+DIV网站建设存在的问题也比较明显，主要表现在：

    第一，对于CSS的高度依赖使得网页设计变得比较复杂。相对于HTML4.0中的表格布局（table），CSS+DIV尽管不是高不可及，但至少要比表 格定位复杂的多，即使对于网站设计高手也很容易出现问题，更不要说初学者了，这在一定程度上影响了XHTML网站设计语言的普及应用。

    第二，CSS文件异常将影响整个网站的正常浏览。CSS网站制作的设计元素通常放在几个l外部文件中，这一个或几个文件有可能相当复杂，甚至比较庞大，如果CSS文件调用出现异常，那么整个网站将变得惨不忍睹。

    第三，对于CSS网站设计的浏览器兼容性问题比较突出。基于HTML4.0的网页设计在IE4.0之后的版本中几乎不存在浏览器兼容性问题，但 CSS+DIV设计的网站在IE浏览器里面正常显示的页面，到火狐浏览器（FireFox ）中却可能面目全非（这也是为什么建议网络营销人员使用火狐浏览器的原因所在 ）。CSS+DIV还有待于各个浏览器厂商的进一步支持。

    用过div+css作个整个网站，如果是纯粹的div的布局是比较麻烦的，尤其是你div里面嵌套div的，div布局的时候，你有些页面效果还是要舍弃 一点的，比如图片的圆角，这些如果套div比较麻烦，在一个div在VS2005设计器里面可能变形，如果过多的套div，你实现ajax拖动效果的时候 比较麻烦，所以我觉得眼下还是div+嵌套table比较好。

    圆角——可以用div+css做出一样漂亮的圆角，而且不用图片，而且是宽度、高度自适应的

    怎么实现?挖挖Google Talk的css模板

    忘掉 div 和 table 吧!

    html 最大的特点就是兼容性和自适应性。

    使用了复杂的 div+css 后，你也许会发现在 IE 中很美观的页面在其他浏览器中看起来象一团浆糊。做一个网站而只服务与特定的浏览器，是不可取的。如果看到哪个网页上有“请用 XXX 浏览”的字样，一个字的评价“烂”!

    html 浏览器会自动根据页面的内容进行排版，这是普通的应用程序难以做到的。做出“请用 X*Y 以上分辨率浏览”的、在高分辨率显示器上浪费了大量页面左右空白而使用长长滚动条的、使用了固定字体大小的，统统都是从开发应用程序转过来的“半路出家的 和尚”。

    千万不要模仿所谓的“XX优秀网站设计”，那如果不是主办方有意的推广某种技术，就是作者的美术功底太过优秀的。一个好的网站，只有先做到内容充实、简洁、合理组织、方便阅读，再去考虑锦上添花的修饰。

    已经完全转型div/css 刚开始还是比较麻烦，动不动就查样式文档，现在基本实现手写。

    推荐用VS2005布局，比如一个页面在VS2005的标准样式布局后，再将一个个样式取出到单独css文件中，这是比较快的办法。

    SPAN 和 DIV 的区别在于，DIV(division)是一个块级元素，可以包含段落、标题、表格，乃至诸如章节、摘要和备注等。而SPAN 是行内元素，SPAN 的前后是不会换行的，它没有结构的意义，纯粹是应用样式，当其他行内元素都不合适时，可以使用SPAN。

    下面以一个实例来说明这两个属性的区别。

    代码:

    SPAN标记有一个重要而实用的特性，即它什么事也不会做，它的唯一目的就是围绕你的HTML代码中的其它元素，这样你就可以为它们指定样式了。在此例中，标识符允许你将一个段落分成不同的部分。

    还有一个标识符具有类似的功能，

    DIV也被用来在HTML文件中建立逻辑部分。但与

    SPAN不同，

    工作于文本块一级，它在它所包含的HTML元素的前面及后面都引入了行分隔。

    效果:

    SPAN标记有一个重要而实用的特性，即它什么事也不会做，它的唯一目的就是围绕你的HTML代码中的其它元素，这样你就可以为它们指定样式了。在此例中，标识符允许你将一个段落分成不同的部分。

    还有一个标识符具有类似的功能，

    DIV也被用来在HTML文件中建立逻辑部分。但与

    SPAN不同，

    工作于文本块一级，它在它所包含的HTML元素的前面及后面都引入了行分隔

-----------------------------------------------------------------------------------------------------对于DIV与table的思考(转自动易CMS论坛)
以下观点谨代表个人看法！

近期动易论坛掀起了div+css热潮，由于div+css是目前世界网页界的一个标准、网站建设的前端，然后加上一些人认为div运行速度一定快于table的观点，使得很多人投身于div+css的行列中来。

但是各位朋友测试过没有呢？div优异于table在什么位置？它到底比table快多少？
熟悉网站架设的朋友都知道，table结构的网站需要先对table进行加载，然后读取table内的内容，而div是直接加载，所以div在一定程度上在加载速度优于table结构的网页。

但这是绝对的吗？


答案是：不一定。


最近，凤凰涅磐做了4个页面进行测试，两个形式的网页，两种网页结构。同样的数据量的情况下，首先的结论是div一定快于table结构，但快了多少呢？ 经过同一个服务器测试，两种结构的页面、同一个数据量的情况，div快于table的速度微乎其微.以调用动易2006beat1核心为例：文章调用5个 栏目，各调用10个标题；下载调用2个栏目，各调用10个栏目；商城调用4个标题+图片；图片频道调用6个图片；网站统计隐藏调用。带宽10M，经过精确 的读秒计算，div结构的网页仅仅比table快不到1秒。由此可见，如果table网页结构的代码优化的好，速度一样可以提升！！！

以模板263三个版本进行测试：测试环境：服务器双至强，20M独享带宽，本地测试连接带宽10M。午夜二时左右开始测试。以目前模板263使用的 VLO8测试时间为：4秒30左右可以全部打开；测试模板263 2006_V2版（div结构）,全部打开为2秒30左右，测试模板263_2006_V3版（div）结构，全部打开时间为2秒。但需要注意的是，模板 263测试的DIV结构网站数据为不完全型，即：数据没有全部加载，但所差的速度为1秒左右。

诚然，div作为一个行业标准会慢慢的走近我们，而作为从事这个行业的朋友和爱好者也是应该掌握的一种技术。但我个人认为，技术和思路都会存在一个盲区， 而这个div就是一个网页行业的盲区，首先我们得知道，动态网站即使生成静态页面的情况，也是有从数据库读取的情况，比如:网站调查。网站统计等。。。。 所以在对于一定的动态网站上速度并没有太大的提高;


而W3C标准很多代码是不能用的，例如：iframe，这些如果去校验的话，都属于不合格产品而已。而对于div结构的网站，手工代码很多，DW编辑中属 于不可视状态（即便可视，也不是浏览器的状态），所以代码需要自己一行一行的敲出来，而后台的css也是同样，而且css用量更大，因为div是用id进 行定义的。但可以肯定的是，div对手写代码锻炼性极佳！！！

就我个人为例：写一个首页代码div+css，用div需要写一天左右，而这个时间，我能做出一个首页+一个频道的首页了。例如：某些表格的边框，我使用table的话，只要填充就可以，而div结构需要对这个ID进行定义，等于加大了css的工作量。

而且作为目前商业发展看，我们最后加工的网页是交给客户，div结构的网页客户如何维护？如果客户能够进行熟练的维护div结构的网页（包含前台的部分改 动），那么他可能已经不需要你了。而table客户拿到后，客户相对可以容易的维护和扩展。而相对的DIV结构的网站造价也要比table高，这仅仅是制 作的费用，还不包括后期的维护！

其实，这里并不是说div有多么的不好，本身模板263也开始制作和启用div结构的模板，只是这种结构的网站需要熟悉代码和结构人使用而已.

而目前动易系统部分结构还不支持div结构，比如：链接标签、栏目模板（如果使用w3c标志会出现500错误），后台编辑会去掉属性引号（在w3c中这是绝对不允许的）.

记得做完检查：IE、Firefox 、Opera三种浏览器的兼容性。

这里只想告诉大家：技术不要盲从！！！


   CSS＋DIV是网站标准（或称“WEB标准”）中常用的术语之一，通常为了说明与HTML网页设计语言中的表格（table）定位方式的区别，因为XHTML网站设计标准中，不再使用表格定位技术，而是采用css+div的方式实现各种定位。

    CSS＋DIV网站设计的优势

    首先，CSS的极大优势表现在简洁的代码，对于一个大型网站来说，可以节省大量带宽，而且众所周知，搜索引擎喜欢清洁的代码（其真正意义在于，增加了有效关键词占网页总代码的比重），因此使用CSS＋DIV的web标准制作的网站具有搜索引擎友好的一定优势。

    其次，CSS+DIV制作的网站使得网站改版相对简单，很多问题只需要改变CSS而不需要改动程序，从而降低了网站改版的成本。

    尽管CSS+DIV具有一定的优势，不过现阶段CSS+DIV网站建设存在的问题也比较明显，主要表现在：

    第一，对于CSS的高度依赖使得网页设计变得比较复杂。相对于HTML4.0中的表格布局（table），CSS+DIV尽管不是高不可及，但至少要比表 格定位复杂的多，即使对于网站设计高手也很容易出现问题，更不要说初学者了，这在一定程度上影响了XHTML网站设计语言的普及应用。

    第二，CSS文件异常将影响整个网站的正常浏览。CSS网站制作的设计元素通常放在几个l外部文件中，这一个或几个文件有可能相当复杂，甚至比较庞大，如果CSS文件调用出现异常，那么整个网站将变得惨不忍睹。

    第三，对于CSS网站设计的浏览器兼容性问题比较突出。基于HTML4.0的网页设计在IE4.0之后的版本中几乎不存在浏览器兼容性问题，但 CSS+DIV设计的网站在IE浏览器里面正常显示的页面，到火狐浏览器（FireFox ）中却可能面目全非（这也是为什么建议网络营销人员使用火狐浏览器的原因所在 ）。CSS+DIV还有待于各个浏览器厂商的进一步支持。

    用过div+css作个整个网站，如果是纯粹的div的布局是比较麻烦的，尤其是你div里面嵌套div的，div布局的时候，你有些页面效果还是要舍弃 一点的，比如图片的圆角，这些如果套div比较麻烦，在一个div在VS2005设计器里面可能变形，如果过多的套div，你实现ajax拖动效果的时候 比较麻烦，所以我觉得眼下还是div+嵌套table比较好。

    圆角——可以用div+css做出一样漂亮的圆角，而且不用图片，而且是宽度、高度自适应的

    怎么实现?挖挖Google Talk的css模板

    忘掉 div 和 table 吧!

    html 最大的特点就是兼容性和自适应性。

    使用了复杂的 div+css 后，你也许会发现在 IE 中很美观的页面在其他浏览器中看起来象一团浆糊。做一个网站而只服务与特定的浏览器，是不可取的。如果看到哪个网页上有“请用 XXX 浏览”的字样，一个字的评价“烂”!

    html 浏览器会自动根据页面的内容进行排版，这是普通的应用程序难以做到的。做出“请用 X*Y 以上分辨率浏览”的、在高分辨率显示器上浪费了大量页面左右空白而使用长长滚动条的、使用了固定字体大小的，统统都是从开发应用程序转过来的“半路出家的 和尚”。

    千万不要模仿所谓的“XX优秀网站设计”，那如果不是主办方有意的推广某种技术，就是作者的美术功底太过优秀的。一个好的网站，只有先做到内容充实、简洁、合理组织、方便阅读，再去考虑锦上添花的修饰。

    已经完全转型div/css 刚开始还是比较麻烦，动不动就查样式文档，现在基本实现手写。

    推荐用VS2005布局，比如一个页面在VS2005的标准样式布局后，再将一个个样式取出到单独css文件中，这是比较快的办法。

    SPAN 和 DIV 的区别在于，DIV(division)是一个块级元素，可以包含段落、标题、表格，乃至诸如章节、摘要和备注等。而SPAN 是行内元素，SPAN 的前后是不会换行的，它没有结构的意义，纯粹是应用样式，当其他行内元素都不合适时，可以使用SPAN。

    下面以一个实例来说明这两个属性的区别。

    代码:

    SPAN标记有一个重要而实用的特性，即它什么事也不会做，它的唯一目的就是围绕你的HTML代码中的其它元素，这样你就可以为它们指定样式了。在此例中，标识符允许你将一个段落分成不同的部分。

    还有一个标识符具有类似的功能，

    DIV也被用来在HTML文件中建立逻辑部分。但与

    SPAN不同，

    工作于文本块一级，它在它所包含的HTML元素的前面及后面都引入了行分隔。

    效果:

    SPAN标记有一个重要而实用的特性，即它什么事也不会做，它的唯一目的就是围绕你的HTML代码中的其它元素，这样你就可以为它们指定样式了。在此例中，标识符允许你将一个段落分成不同的部分。

    还有一个标识符具有类似的功能，

    DIV也被用来在HTML文件中建立逻辑部分。但与

    SPAN不同，

    工作于文本块一级，它在它所包含的HTML元素的前面及后面都引入了行分隔


1.网页背景色的设置



犯错机率：很大
普遍性：较广
犯错可能性：懒/不知道



约2年前我曾发现21cn上出现过一次没有设置背景色的情况，当时我用Email通知了他们，自此之后这个问题我从没犯过。



绝大部分人的窗口背景颜色都是白色，但如果象我这样个性的人，就会把windows窗口的背景颜色改成灰色或其他色，这样一来，如果你没有设置网页的背景颜色的话，你以为正常的网页在我的电脑上看起来会是一团糟。



2.Align center（自动居中）的滥用



犯错机率：非常大
普遍性：非常广
犯错可能性：以为方便/以为好用



工作中，修改、维护别人的网页是家常便饭，发现不少人有一个陋习：
在表格中的文字或图片，你是这样来令它居中、靠左或靠右过？

大家好啊！！

当有些表格很多、文字很多、内容分得很细的时候，爱用这种方法（它在DW里的快捷键是Ctrl+Alt+C，FP不知道是什么）的人往往会狂用，惨了，我 一碰到这样的网页就头痛，为什么要用那么多

来居中呢？tell me why？难道表格没有居中属性吗？为什么要加入这些垃圾代码？特别修改的时候也不能把文字或图片删除了就能自动清除

这个代码，还要手工去清除，在复杂点的网页中就会无故地浪费维护者一笔时间。



建议使用     来居中，当需要多重定位的时候，才考虑

，因为这个代码并不好处理，所以能用表格代替就用表格替代。



3.重复使用实现相同功能的代码、或杂七杂八的乱套代码



犯错机率：非常普遍
普遍性：非常普遍
犯错可能性：复杂多样



大家先来看一看下面的代码：

标 题
你觉得这样的代 码看起来感觉怎么样呢？

我不知道读者有什么感觉，压根我一看到这样的代码就会先自我麻木十来秒，这十来秒目的是为了找一个能表达我的思想感情的词（我？你想反问我吗？sorry~~，我一般不犯，因为我做网页至少有一半以上的时间在浏览代码，代码中多了不该多的东西我一眼就能看出来。）。



看看上面的代码，使用了2个class，4个font来定义2个文本，其实这样的问题很多时候是在大家不断的修改中产生的，对代码不熟、或懒查看代码、又 或不喜欢查看代码的人犯这些问题特别严重，当然，事实上别人浏览这个网页的时候，是没有任何问题的，但维护的人就…………。
这些多余的垃圾代码完全是可以省略掉的，其实上面的例子不够严重，更恐怖的我都见过。



另外还有一个问题也要提提的，就是

...

和...，为什么要用它们呢？tell me why~~，有甚者是这样的：



   

标 题
< /td>你觉得这样的代码看起来感觉怎么样呢？

< /div>



看到这样的代码我是会很无奈的（更无奈的是我经常看到，而且必须看），我来简化一下：
   
标题
你觉得这样的 代码看起来感觉怎么样呢？



是不是看起来觉得这个世界安静了很多？"标题"后面的文字完成可以定义在     的class里，就算不用css，再用多一个<.font>也没问题，一样很清爽。



4.表格不正确嵌套



犯错机率：一般
普遍性：普遍
犯错可能性：对这个不了解



其实这是一个街知巷闻的问题了，但还是不断有人犯，不正确的嵌套表格，可能会令到你被老总叫到办公室里臭骂一顿，会令到你以为正常的网页用ADSL开2、3分钟都开不了。



先讲第一个问题，就是在一个大表格里不断地嵌套表格，这样会令到打开网页的速度变慢（虽然说现在的IE改善了这一问题，但还是不建议这样做），另一方面维护、修改也极不方便，一般来说简单的套用是没有问题的，甚至3、4层，但是不要把所有内容都放到一个表格里去。



第二个问题就是在一个大表格里放入所有内容，而其中包括一个免费的计数器代码，嘻嘻，你猜有可能出现什么情况呢？其实也没什么大不了的，最严重的就是你的IE象死机了一样，什么都没显示。解决方法就是把计数器单独放在一个表格里，别和其他内容一起放在同一表格。



5.写代码缩进的时候，不是使用Tab而是使用空格



犯错机率：一般
普遍性：较少
犯错可能性：不知道Tab更好用



这一个问题针对js、vbs、asp、php之类，html不能使用Tab会写一点程序的都知道什么叫缩进，怎么样缩进？有人使用空格，有人使用Tab，如果你是使用空格的，那么从现在起，改用Tab吧。



使用空格有二大坏处：1、缩进速度慢、修改速度慢。2、增大网页体积，会影响速度。


-----------------------------------------------------------------------------------------------


译自 An Objective Look at Table Based vs. CSS Based Design

我和作者的观点差不多.标准好,但是未必实用.

以下是ZT文章:

经年以来，许多优秀的文章都在赞美着基于 CSS 设计的优越， 哀叹着基于表格设计的没落。但却很少有人换个角度想想，或许是因为你得在了解并运用了基于 CSS 的设计之后才可以批评它， 而一旦了解了之后，你又不愿意回头去用原先的老式设计方法了。

为了弥补一下这种不平衡，也因为在这场游戏中扮演一个大反派挺酷的，我决定写篇文章，说说为何在某些情况下，传统的表格设计方式就算不比基于CSS 的——或者说基于标准的——设计方式好，也不比它们差。

一、妖魔化表格

表格出现以前，Web 本是个相当乏味的地方，正是使用表格排版，才打开了可视化的页面设计的新局面。表格对于 Web 和 Web 设计领域普及的贡献到底有多大或许有争议，但一旦离开表格，我们这些网页设计师们必会失去工作，却是毋庸置疑的。

近年来基于表格的设计确实被妖魔化了，Web 纯化论者会告诉你，表格对排版毫无意义，因而你绝不能用到它。然而历史证明，许多技术一开始是为了实现某个目标设计的，却在别的领域发现了更大的用场而大 展身手。 就像 Web 本身，一开始不也只是为了共享研究数据嘛，现在在娱乐和商业方面的应用却与信息与教育方面的并驾齐驱了。

二、只为舒服一点

Web 设计师们多年以来都在使用表格排版页面，这是绝大部分设计师都已掌握的能力。如此地使用表格能保证你获得预想的效果，通过一些简单的 hack，比如间隔 gif， 我们几乎一定能保证我们的站点在最广泛的 Web 浏览器上看起来都一样，从最低版本的 Netscape 4到Safari 这样的现代浏览器。

尽管先驱者们早已宣传了好久 Web 标准， 大部分的网站还是使用表格和不兼容标准的代码开发的，因此用户代理就不得不在很长一段时间内支持基于表格的排版方式。 这对于 Web 标准的卖点来说，是个致命的打击：标准没有标准应有的地位。不大可能会出现下面这种情况，某个主要的浏览器厂商 (唔，还是说 Microsoft) 突然发布了一个大部分网站都显示不了的浏览器。

所以网页设计者们总感觉不到开始使用基于 CSS 排版和支持标准的代码的那种危机感和必要性。

三、降低门槛Web

正是因为它的门槛低才如此成功的： HTML 是个简单易学的语言，浏览器又能容忍许多标记混乱的文档。 这使在 Web 上发布内容变得难以置信地容易。即便你 12 岁的侄子也能用 Microsoft Office 中附带的 Frontpage 捣鼓出一个简单的网站来。

基于表格的设计比之基于 CSS 的，当然 CSS 的语法很简单，正常人都会同意：你没必要是火箭科学家才能学会 CSS。尽管如此，其中有些概念还是过于微妙了，不易领会。比如表面上看，Box 模型很简单，但我偶尔还是会在边界折叠 (margin collapsing) 上滑一跤， 浮动(float) 和清除 (clear) 这样的概念也不好理解，较难运用。 以我的经验而言，从了解 CSS 的基本概念到能自如地用 CSS 开发站点，大约需要走过一条为期 6-12 月的学习曲线。

然后是浏览器支不支持的问题。一旦你正式开始干活，就会慢慢了解哪个浏览器支持什么、不支持什么，和一些常见的浏览器 bug。可惜bug 太多了， 就算“专家”们也难以估量自己花在修整 bug 上的时间。对新手来说就更让人泄气了，因为他们不知道是因为自己误解了CSS 呢，还是某些晦涩的浏览器 bug？也许这就是为何同样的问题一再出现在 CSS-Discuss 等邮件列表上的原因吧。

如果浏览器厂商们终能步调一致， 用 CSS 开发站点将会容易得多。但我还是觉得——大部分人也会同意——CSS 开发的门槛比基于表格的还是太高了。换个说法， 我觉得这也说明了为何基于 CSS 的设计在Web 专家们之间如此流行。这让他们把自己和那些业余的“Front-page 牛仔”们区分开来，让他们找回当年 Web 只属于自己这个小群体时的感觉。 大概这正式因此，那么多人都把 Web 标准看作不可触及的“象牙塔”， 那么多 Web 标准的鼓吹者却以狂热的态度，带着优越感去看待网页设计。

四、有些东西还是用表格来做更容易

我确信我们大家都曾发现，自己为了实现用表格做起来是小菜一碟的功能写了相当复杂的 CSS。比如处理表单 (form) 的外观，形状再复杂怪异的表单也能用表格轻松搞定。 你是可以用 CSS 的浮动元素实现类似的结果，但就麻烦多了。 如果你是个 CSS guru，这种麻烦也是快乐的事。可毫无疑问，如果你只是个普通人，还有个会掐住你的喉咙问你怎么做个小表单也花了这么久的老板，事情就不那么好玩了。

如果你有足够的知识，又有足够的耐心，习惯于用表格做的大部分事情还是都能用 CSS 实现的。 虽说花的时间长点吧，还是有个限度的(或者被打击得放弃了尝试)。关键是确实有些无论你怎么努力，还是无法实现的东西，其中一项便是页脚栏 (page footer)。我常常见到来自灰心失望的 CSS 作者的贴子， 他们试图创建那种可以粘在窗口底端的页脚栏，使即便那个窗口没伸展到整个屏幕也能保证效果。如果用到了表格，要做出这种效果简单得很， 可单独用 CSS 来做就是另一回事了。 为什么还有 Web 开发者们不愿意用 CSS？就是因为一旦不用表格，简单的事情反而变复杂了。

五、夸大收益

有很多理由让你丢掉表格、去适应基于 CSS 的排版， 可在推动 Web标准的洪流中，许多人夸大了收益。 大的站点改用 CSS 排版确实能节省不少带宽。可对大部分的其他站点来说，受益小得庶几可以忽略不计。

大家都希望页面载入得更快， 而标准鼓吹者们也说 CSS 能帮你做到这一点。大多数站点的“设计”都是均匀分布在整个站点上的，但基于 CSS 的“设计”是放在一个到更多的文件中的。 这些文件会很快变得很复杂、很大，即便一个小站点也是如此。我最近设计的一个站点用了 4 个样式表，加起来有 12k 之大 (虽说包括了空白和注释)。使用 CSS其实是在先集中地载入然后再浏览，而不是把要载入的数据平均分布到整个站点各处。也就是说，相比用表格排版，首页需要花更长的时间来下载。只不过如 果样式表已经下载了，它们会被缓存起来而不需要重新下载。可毕竟一个站点的首页是你最不希望载入得那么慢的一页呀。

六、招揽客户

即便有时网页设计者们觉得把符合 Web 标准搭售给客户是有必要的，但令人遗憾的事实是，大多数的客户对站点的代码好坏并不在意。我们一般用的是胡萝卜加大棒的方式，胡萝卜是诸如对搜索引擎的友好度之类，而大棒才是网页的亲和力 (accessibility)。

确然，搜索引擎是比较喜欢语义化标记的页面，而且大家也都认为搜索引擎喜欢短小的代码，通过 CSS 和 Web 标准来建构站点可以大大增进对搜索引擎友好的站点的开发。然而没有银弹。许多基于表格的站点照样获得了很高的搜索引擎排名。 用 CSS 开发的站点照样也可能只获得一个很糟糕的排名。高排名的关键是内容和来自别处的链接，而不是用表格还是用 CSS 来排版。

另外关于利用客户对“亲和力”这个词的敬畏来搭售 Web 标准特别是 CSS 设计， 其实基于表格的设计没有什么天生的亲和力缺陷，表格只要线性化了，就有意义，内容也就具有亲和力了。现时的读屏器技术已经不错，而且大部分的读屏器都能很 好的支持基于表格的站点。当然你的站点的语法最好被认证通过 AA 亲和力等级，即便对更严格的 AAA 等级，不用表格设计也不过是个建议罢了，并非必备。

另一个经常提到的受益是可以让客户独立于设计提供商。在人人都依照标准开发的世界里，客户要换个开发伙伴是很容易的事情，新的开发人员可以很快明白站点的 组织结构，而不需趟过先前某人的标记泥淖。但这得要大量的设计提供商都精通 Web 标准才行。 不幸的是，现在的情况并非如此。 虽然经验丰富的 CSS 开发者在增多，但这还是个相对比较专业的领域，因此，大公司要锁定在这种开发方式上还是比较有风险的——缺少熟练的开发者。我个人的经验是如果一个组织要 用 CSS 开发站点， 得长期保持至少一个经验丰富的设计师才够用。 所以现在转向 Web 标准不是降低了客户对开发者的依赖，而是增加了。

七、总结

毫无疑问地，Web 标准和基于 CSS 的设计是未来之路。 可在我们奔向它们、鼓吹新技术的过程中，也会怀疑自己鼓吹的东西是否太夸张了。比较现实地做点东西却往往达不到我们的期望。而教条地推行这些很可能疏远了我们最应该赢得的伙伴。

基于表格的设计还会存在好长一段时间。要吸引开发者，我们可以用实例来教人上手，并降低门槛。更别弄出新的门槛来了。我们得诚实地正视利益和代价。 开发 CSS 站点可能比较困难、耗时，而在某些情况下用表格来排版比 CSS 有意义得多。


近来大家总是在标准上争论不休，其实，这些问题一些相关文章已经说得很明白了。

以下我就谈谈我的看法。本帖子有太多的“我认为”，说明了我只是想把我的想法拿出来跟大家商榷，或许有太多不对的地方，也请大家一一指出。

1、我对web标准的理解

所谓的web标准，在一些教程文章上已经得到结论：结构化标准（XHTML、XML）、表现标准（CSS、XSLT？）、行为标准（DOM、ECMAScript）。这些东西在网上一搜一大把，在这里我就不多说了。我只说我自己的想法：

a.标准是相对的，有其一定的局限性

作为标准本身，它也在不断地完善中。我们也可以加入其中完善它，而不是盲从它。没有最好，只有更好。（LeXRus前一阵子说要成立自己的web标准组织，不知道现在怎么样了。）

b.标准只是被推荐使用，好的标准大家都会自觉去遵守

我们之所以使用标准，就是因为标准对我们有利。正如现在倡导的ISO9000标准一样，它只是倡导，并不强迫。我认为它对我有用，所以我用它；同样，如果 你认为它实在不怎么样，你也可以不用它，标准本身不应该带有任何强迫性。就跟打篮球一样，NBA是24秒进攻，我们是30秒进攻，我们要想加入NBA，就 得用人家的规则。还有我们加入“世贸”也是，如果我们够拽，自己成立一个“世贸”，自己发布一套标准，也是可以的。

c.标准没有明确提到用div还是table

有些朋友很容易把标准简单地等同于“把table换成div”。我不这么认为，因为table也是符合xml规则的。含有table的页面照样可以通过XHTML1.0的验证。

d.“div布局”不只是用div进行布局

我们可以用一切可能的标签（包括table）对页面进行布局，目的就是要达到最优。它只是提出一个概念，一个全新的模式。坛子里也有人说过，“重要的是观念上的更新，而不是代码。”当然，我们的最终目的是代码的更新。

e.XHTML验证是手段，不是目的

有时，我们用javascript来生成flash movie代码，以欺骗validator，通过验证。用这种方法，那么没有通不过验证的页面。如果只是玩玩，那是可以的。但是我怕会有些初学者太把 validator当回事，甚至认为通过验证是最终目的。我的看法是：validator不过是一个工具，它帮助我们检查我们的页面是否符合标准，仅此而 已。最终我们还是得按客户的要求设计我们的页面。

2、我为什么要用标准

有人会以为使用标准的目的就是为了达到标准。其实，《网站重构》一语道破天机：为了网站能“活”得更长久，为了提高网站的可访性，更为了降低成本，我们必须采用Web标准！这里有三个“为了”，没有一个是为了标准。标准只是手段。

接触“标准”后，我尝试去做一些符合“标准”的页面。当时，并不是很明确为什么要使用标准，只是出于一种好奇心理。中间也遇到了一些难题，有技术上的，也有观念上的。但是，现在我很乐意用div+css来给客户做网页。

用了标准以后，给我的感觉就是：代码精简了，维护方便了。

代码精简，可缩短页面装载时间。就算在当前宽带的条件下，我们也不应该放宽对自己的要求——精简代码（我想这也是每一个程序员对自己的要求），况且现在还有不少的拨号用户，以及手机上网/浏览的用户。这是一个分秒必争的社会。

严格按照标准，可以获得更高的兼容性。一个合格的网页制作者，他总是试图让网页达到最高的兼容性。当然，他要在效果与兼容性之间取得某种平衡。就像我们现在挑老公：既要有钱，也要靓仔。

维护方便，我甚至只要修改一下css就可以让整个页面呈现出完全不同的风格。这可以节省不少工作。

当然，我认为用标准最重要的一点是：向后兼容。用一个专业的术语就是：可持续发展。网络总是在不断地发展中，一个好的网页制作者，总得对未来的发展有一定的预见。就现在我知道的，以后一段时间确实是xml的天下，直到有更好的东西出来取代它。

每年都有太多的网站为了跟上时代，花不少钱在改版上。因为改版就意味着一切重来，包括代码，甚至程序。

标准还要求我们把数据交给XHTML（或者html、xml），把表现交给css，两者各司其职，结合起来。

3、为table平反

《网站重构》一书出来以后，也许有很大的误读成分，一些朋友把标准跟重构混淆了，甚至等同起来。我没看过这本书，不好做评价。

“在不改变代码外在行为的前提下，对代码做出修改，以改进程序的内部结构”，这就是重构。我认为“网站重构”兼有“div布局”跟“web标准”的意思。布局讲的是一种方法，标准讲的是一种规范，这是两码事。

web标准并不是说不用table，我找遍了网上的文章，没有找到一篇文章说web标准反对使用甚至建议不使用table标签，我想它是这样说的：建议不要使用table“布局”，而改用div+css“布局”。

拿一个数据表来说，我认为用table来组织它是最好的解决方案。当然，你要用其他办法来实现也是可以的，但是我敢说都没有table来得简单、简洁。（也许有，只是我没找到？）当然，在学习阶段，强制自己不使用表格解决一切问题，还是蛮有用的。

以上说了这么多，与其说是我的想法，不如说是汇总了大家的想法。但求不贻笑大方，如果能对初学者有所裨益，那就阿弥陀佛了。