*以下文字為搜集一些網站或論壇里面的文章，不代表本人觀點，僅供參考。 南京網站建設 恒網========================================================

其實并不是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來得簡單、簡潔。（也許有，只是我沒找到？）當然，在學習階段，強制自己不使用表格解決一切問題，還是蠻有用的。

以上說了這么多，與其說是我的想法，不如說是匯總了大家的想法。但求不貽笑大方，如果能對初學者有所裨益，那就阿彌陀佛了。