經驗之談！解讀Div+CSS網頁製作迷思

「重構」的春風吹遍大江南北，互聯網一時間風聲鶴唳，“div+CSS”儼然已成為一種“時尚”，難以盡數的網站都不約而同地開始了自己的“重構”。然而打開這形形色色網站的源代碼，卻時常令人啞然失笑——

我們看到有嵌套6、7層的div佈局，有不用table的表格，有純div+a構成的頁面，有成百上千的表現層class……現在關於標準的書籍越來越多，除了少數幾本標榜「高級技巧」的書籍以外，很少有人不會在自己著作的前幾章強調這樣一句話——「結構與表現分離」。然而這些書籍的讀者們，有多少人認認真真地讀過前幾章呢？還是更直接跳過那些乏味的結構講解，一頭扎到貌似高深的佈局技巧與Hack中去？

其實div+CSS這個說法從一開始就誤導了太多的人，而急功近利的心態則更是造成這種現象的罪魁禍首。一個習慣了table版面的網頁製作接觸標準的第一步，不應該是去盲目尋求實現各種版面的CSS技巧，而是努力改變自己的思考方式。

以下將結合我的切身體會談一談順應標準的思維方式，其中有不少是我曾經走過的彎路，希望對剛接觸標準的XDJM們有些幫助：

1.「節省代碼」是行銷手段，不是宗旨

“使用div佈局可以比table佈局節省更多的程式碼”，我在許多書籍和網站上看到過這句話。這句話本身是沒錯的，可以「節省程式碼」的確是網頁標準化所帶來的好處之一。然而切記，它只是“好處之一”，而不是“唯一好處”，更不是宗旨。 「節省程式碼」更多的時候是我們用來說服那些頑固不化的老闆的行銷手段。網頁標準化的唯一宗旨是“結構與表現分離”，而絕不是為了節省程式碼而節省程式碼。我曾經因為網站邊欄甚至主體內容的表現形式相同而採用了統一的class （至今還有一些書是這樣教的），這樣的確比分別命名id更節省代碼，然而這樣做的代價是代碼失去了良好的結構。失去良好結構的後果是：一、原始碼沒有了可讀性；二、網站增加了未知的維護成本。試想，當某一塊內容因為需要而作出表現形式的變動，例如連結的顏色等等，我們就不得不去修改頁面來源文件，增加額外的class，工作量比起只需要調整id分組就大了許多。而且長此以往，結構將會越來越差，形成難以逆轉的惡性循環。

還有一種情況，出現在id的命名方面，也是本人曾經犯過的錯誤。那時為了“節省代碼”，而把主選單命名為“mm”，二級選單命名為“m2”，三級選單為“m3”，結果嚴重降低了網頁的可讀性，使其他同事很難接手，圖省事卻累了自己。同理，文件及資料夾命名方面也不宜過簡，象《網站重構》裡建議把圖片都用「i」目錄存放，個人以為並不可取，除非你能為這種高度縮寫的目錄結構撰寫詳細說明並保證每個相關人員包括其他製作人員、開發、甚至懂行的老闆……都能理解和執行，否則只會給你自己增添不必要的麻煩。

2、ID是狙擊槍，class是雙面刃

想要做好網頁結構，id與class都是必須熟練的，所謂「兩手抓，兩手都要硬」。 ID就像狙擊槍一樣，可以幫助我們精準地定位要想要加載樣式的元素；而class則是俠客的佩劍，信手拈來更加輕盈靈便，兩者的結合能夠實現結構良好且表現豐富的頁面。然而現在有一種錯誤的觀點，就是id完全可以用class來取代，事實上許多網頁原始碼也的確如此，打開來通篇class，找不到一個id。造成這種現象的理由有很多種，然而自table時代傳下來的根深蒂固的「class=CSS」的觀念才是本因。的確，class比id用途更廣更靈活，但也必須意識到，class對於建構良好的網頁結構遠不如id有效。 id的強制唯一性使得我們可以輕易地透過id檢索到我們需要的任意模組，而class則沒有這個優勢。雖然我們可以為模組定義唯一的class名，但前提是──只有製作者本身可以動網頁樣式。否則換一個稍微懶一些夥計，看到樣式相同便直接把前面的class拿來應用，其結果就是我們發現網頁裡有十幾個模組都叫做“gonggao”或者“xinwen”，以至於為了區分還不得不加上大量的html註釋，這樣的結果顯然不是我們想要的。再者就是前面提到的，透過通用class節省下來的程式碼，又不得不在每個單獨定義的class中揮霍掉。

ID是狙擊槍，class是雙刃劍，合則兩利，分則兩敗。

3.並不是所有的內容都需要div做“容器”

主選單究竟是用