Div+CSS網頁製作誤區

“網頁重構”的春風吹遍大江南北，互連網一時間風聲鶴唳，“DIV+CSS”儼然已成為一種製作網頁的“時尚”，難以盡數的網站都不約而同地開始了自己的“網頁重構”。

　下面將談一談順應標準的思維方式，其中有不少是我曾經走過的彎路，希望對剛剛接觸WEB標準的兄弟姐妹們有些協助：

　　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做“容器”

　　主菜單究竟是用<div id="mainnav"><ul>還是<ul id="mainnav">？這是一個博弈的問題。至今這個問題也沒有人能夠給出明確的答案，就連我也是如此。誠然，<div id="mainnav">在只包含了一個<ul>元素的時候，這個div就顯得有些冗餘，但有時候為了配合美工絢麗的設計，多一層標籤就意味著多一層變化（有些人在a標籤裡套span也是如此）。而div不帶任何原始屬性的先天優勢也是其它標籤所無法比擬的。這個命題我只是想說明一件事，就是我們應該意識到，<div id="mainnav"><ul>之外，還有<ul id="mainnav">這種寫法，同樣具有良好的結構和語義，並且省去了一層嵌套。在我們不需要為華麗的美工勞心勞神的時候，是不是也可以讓結構更加簡約呢？

　　這個命題其實還可以引申為——“並不是所有內容都需要塊元素做容器”、“並不是所有連結都需要其它元素做容器”，例如很多頁面都有的“更多”。有些人寫做“<div class="more"><a>”，也有人寫做<p><a>或者<strong><a>。在這些“容器”只包含了一個<a>標籤的時候，它們是否還有存在的必要？直接寫成<a class="more">會破壞結構嗎？會缺乏語義嗎？會影響布局嗎？換一種思路，你也許就會有不一樣的收穫。

　　4、工作上也做到“結構與表現分離”

　　關於這一點，網路上很多高手都是這樣建議的，也就是先開啟編輯器，把結構完整地寫出來，再去CSS裡寫表現，而盡量不去動已經寫好的結構。

　　然而以看書為主要學習方式的人卻很難體會，因為關於標準的書籍多半是手把手來教的，也就是必然是結構表現結合，循序漸進。雖然有些書籍有這方面的建議，但短短的幾句話遠不如讀書過程中的潛移默化。在製作人員能夠對結構良好把握的時候，同時寫結構與表現也不會對結果有太大的影響。但以我的經驗，結構表現分離的工作方式，要比同時寫結構與表現效率高很多，同時也不容易遺漏頁面上的元素。

　　當然，所謂的“結構與表現分離”並不是完全不考慮表現，想要兼顧到表現，就要保證——在不破壞結構的前提下，CSS選取器能夠選擇到盡量多的內容。在哪些地方加class，或者用哪些標籤來區分，是一個見仁見智的地方，相信每個人都有自己的體會。而結合不同的設計稿，有時候也需要做出相應的變化，然而這些變化都應該有一個同樣的前提——不破壞代碼的結構和可讀性。

　　再就是，一定要意識到，任何可視化的工具都是魔鬼。它們可視化介面下所呈現的效果，往往與真實瀏覽器相差千裡，而我們真正要相容的是瀏覽器，不是編輯器的可視化介面。

　　5、CSS不是萬能的，沒有CSS也不是萬萬不能的

　　相比於CSS1.0時代，今天CSS可以完成更多的事情，然而需求永遠是領先於技術的，CSS無法完成網頁所有的表現層工作，有時候我們必須結合JS或者其他語言來實現一些效果。而另一些時候，用JS的方法比只靠CSS簡單得多，並且代碼結構更加良好——最典型的例子就是下拉式功能表。這些時候，我們要說服自己，或者說服老闆與客戶，去採用更簡單更合理的方式。因為DOM同樣是網頁標準的重要組成，並不是使用了JS我們的網頁就降低了效率或是不再標準，恰恰相反，這是對JS最大的誤解。說到這裡不得不提一點，就是今天的時代，比以往更要求每個職業瞭解更多的相關知識，做設計的人要懂一點互動和製作，做製作的也必須瞭解設計和程式，尤其是JS這樣的前端技術，只有這樣，你和同事才能夠更好地合作，個人的發展前景也會更加光明。

　　沒有CSS，指的是當我們的網站因為各種未知的原因導致CSS檔案載入失敗，不要因此而慌亂，這是考驗我們代碼品質的最佳時機。在沒有CSS的時候，如果網頁仍舊保持良好的可讀性，這成果要遠比通過W3C驗證更值得我們自豪。