深入CSS結構：合理運用div和span

css

　　特意上網搜尋了一下，關於div，說法很多。

　　把div看成是布局元素這種觀點我想是最多的，類似有“用div代替table進行布局”、“實戰CSS+DIV布局”等等等等，太多了，還有不少人延用Dreamweaver的定義，稱div為層，按Photoshop的層的概念來使用……有朋友乾脆就直接稱div和span為輔助布局元素。

　　怎麼說呢？雖然我很想說對div類似的這種認識是錯誤的，div不是一個布局元素，沒有一個tag是用來布局的，但是我是對的嗎？我也不知道。幾乎所有人對div的宣傳都是布局，不管是‘民間’的還是‘官方’的，但是如果我們找根源，中文中，div是一個結構化標籤，是一個區塊層級元素。好吧，我們首先看看div擁有的語義，division（分隔），按語義它的作用是將兩個部分分隔開來。然後我們再回到w3去看看怎麼定義div和span的：The DIV and SPAN elements, in conjunction with the id and class attributes, offer a generic mechanism for adding structure to documents. These elements define content to be inline (SPAN) or block-level (DIV) but impose no other presentational idioms on the content.

　　注意到我上面加粗的一句話了嗎？W3可沒說是 for layout，而是for structure，是結構！因為分隔從而產生（定義）一個代碼結構。我想，結構和布局應該是兩個概念吧。或許，因為table確實被用於布局了，所以這種根深蒂固的布局思路又自然而然的轉嫁到div上，我曾在很長一段時間裡也是這麼理解的。但是，現在我要說，這絕對是一個錯誤並且，這是極度嚴重的錯誤！！！這純粹個人觀點個人理解，自己取捨好了。

　　為什麼嚴重？理解的錯誤直接導致的就是使用的錯誤。因為如果按照這個思路，把div作為布局元素使用，那麼我認為：

　　你永遠無法固定xhtml！永遠陷在css的怪圈中！永遠不會去思考和理解結構！永遠擦不乾淨table烙下的痕迹！永遠無法接近神（貌合神離的神哈，呵呵）……

　　或許把div稱為布局元素還是為了更好的推行標準，但是卻將人們從一個錯誤帶向了另一個錯誤。兩年前我剛接觸標準時就在《重構之美》首篇中迷惑過關於改版的事情，雖然隨著理解的深入好像有了突破，在我寫下xhtml後不變動，然後通過css的技巧來完成新版面。比如像著名的csszengarden。但是很快我又有新的迷惑，一個人這樣做好像沒什麼問題，團隊呢？比如如果同樣的內容，設計成兩個版式，然後交給不同的兩個人來寫xhtml，會一樣嗎？就像如果把csszengarden的形式顛倒一下，基於同一份資料先做好100個設計稿，讓100個人按照這個設計稿寫100份xhtml，會一樣嗎？我想按照div配置模式，對於同樣的版式，不同人不同的頁面分析都會產生不同的xhtml，更何況不同的版式呢？但是既然表現與結構無關，那麼同樣的內容不應該有2份以上的xhtml。不要小看這個問題，對於團隊中前背景有效分離與快速協同，這是關鍵！我在培訓中提出一個觀點：最理想的境界是前台閉著眼睛都能知道後台輸出的是什麼樣的xhtml結構代碼。那麼問題出在哪裡？div布局！尤其是在理解了h系欄標籤不合理之後，體會更深刻。

　　上篇文章我提出的關於結構應當分為兩種：語義結構和代碼結構。理解了這兩個結構之後，那麼div的用處就比較明朗了，稍稍動動腦筋就能想到，用於組織代碼結構。所以hx標籤的問題我認為經典呢，不要說html了，即便對於xhtml，大部分的人關心的仍是如何表現，小部分人關心語義結構，很少人去關心代碼結構，似乎xml有了，xhtml就不需要代碼結構了。但是從hx系列的問題可以看出並延伸知道W3可一直在關心代碼結構，從1.0，1.1直到2.0，一直希望xhtml擁有xml般嚴謹的代碼結構。說到這裡再多看xhtml 2.0的另一個變化，br不再被推薦，應該很好理解了，br的語義是產生一個截斷（break），但實際作用是產生一個行，語義結構上仍不完美，所以使用line進行替代<line>this is one line</line>。同樣br也無代碼結構可言，如果我想提取第三行的資料如何操作？所以很有可能類似br、hr這類標籤都將被廢棄。我琢磨著，xhtml1.x是W3清理表現，將人們往語義結構[Semantic]的方向牽引，而xhtml 2.0則是展示和突出代碼結構[structure]。呵呵，您說我琢磨得對嗎？瞎猜瞎猜。^_^

　　回過頭來，那麼怎麼組織？首先對於一個設計稿，一定要不被設計所迷惑和左右，只提取看得見和看不見的資料，然後就扔掉設計稿，先完成資料的語義結構，再添加代碼結構（adding structure to documents.），完成xhtml後，最後一步才是重新拾起設計稿開啟css，還原。當然實際做的時候不可能不看設計稿，但是怎麼看？只提資料！再說一點，資料在文檔中的先後順序由什麼定？當然是由文檔而定，不是由設計稿所定。舉個例子，假如有兩個欄目，新聞頭條和普通新聞。誰在前誰在後，很顯然在文檔中應該是頭條在前普通在後，這是由UE（使用者體驗）和欄目輕重的綜合考慮決定。但是按照div布局的話，是按照設計稿上前下後左前右後的順序來決定的，那麼如果設計稿中將普通新聞欄目設計在左欄，頭條設計在中欄，文檔中普通新聞就跑到頭條新聞上面去了。所以我開啟一個Web標準網站文檔瀏覽，如果文檔的先後順序是按照頁面配置上前下後，左前右後的順序而定的，那麼我……特例一點，如果一個單屏設計的網站，標題和導航設計在頁面下方，那你的文檔豈不是最下面才是標題和導航，這是什麼UE？這不是扯蛋嘛。div，div布局的惡果——文檔結構仍然在為表現所左右！貌合神離！！

　　代碼結構怎麼做？大處按照上篇文章所寫，用h系列劃分大結構。那麼小處呢？這裡就要牽涉進div的另外一個概念：區塊層級元素。什麼塊？模組！用div模組化小處。舉例：

<div>
    <h3><span>使用者登陸</span></h3>
    <div>
       <label for="name">使用者名稱</label>
       <input id="name" />
    </div>
    <div>
        <label for="pw">密碼</label>
        <input id="pw" />
    </div>
    <p><button /></p>
</div>

　　這個在[複雜表單]中提到過的例子，我們來詳細分析div在小處如何模組化運用。其實很簡單，h3/lable/p是語義結構，然後，對於使用者名稱和相應的輸入框顯然是不可分割的整體，那麼好了，div將其標識為一個塊，對應的密碼部分同理。最後，兩者一起與標題和按鈕又構成一個不可分割的登陸整體，div之。這樣擁有很好的語義結構和代碼結構。好的代碼結構不僅僅可以便於固定xhtml，便於程式動作節點，還對css提供了很高的自由度。如上例結構，我只需要給最外div一個class，比如"loginarea"。那麼：

　　我可以這麼按節點/路徑層層定義下去：.loginarea label{} .loginarea input{} .loginarea div label{} .loginarea div input。如果我需要橫向登陸，只需要定義一個關鍵點：.loginarea div{float: left}，如果縱向則去掉這個關鍵點，模組化的登陸就這麼簡單。這樣還可以省寫不少class，尤其對於有些看似複雜的結構其實模組化設計好了，模組內部是簡單的，一個路徑定義過去，根本無需class還不會引起樣式衝突和幹擾，css的可讀性也很好。當然這裡會涉及到css的技巧，我認為css的技巧最重要的就是分析頁面，頁面分析的好，寫出來的css簡單明了充分利用tag還有多以備擴充，否則class一大堆複雜冗長還會覺得tag不夠用又去添加破壞結構。複雜表單那套系統的css我寫了48k，還未做最後最佳化，全部圖片總共只有5K，還全是無損PNG格式。整套系統幾十個大模組，又有無限級菜單、樹、頁簽、彈出，複雜表單，合約，frame，iframe，報表，控制項套控制項等等亂七八糟什麼都有，css加圖片全部表現部分可以做到50K以內。這個項目四個程式員一起開發我一個人頂所有前台，三個月時間，程式員不管任何有關表現部分，我都是玩玩做做就搞定了。中後期，臨著交付客戶時候我還覺得公司提供的設計不好，又自己花1天重新設計，花不到2天另外寫了一個css，整個系統全變了且以前的設計未丟失。功能不變的情況下介面大換，再大的系統也不過一個人幾天時間，且程式員不用管。這就是Web標準的威力之一！（因為是內網應用，所以我幾乎沒考慮和照顧瀏覽器安全色性，沒必要，也是快的一個因素）

　　所以我認為當前各大網站上以各種方式事先列出什麼單行一列，兩行一列諸如此類的幾行幾列的div＋css布局代碼，不好說他們不對，你完全可以去理解是如何使用css實現幾行幾列的布局，然後合理運用到自己的結構上。但是如果你按照他提供的代碼去套、去新增內容，那麼你就錯了。不過話說回來，在被一篇一篇標題著鬥大的“布局”兩個字的潛移默化下，您還有心思去關心結構嗎？所以很多都去琢磨css了，所以這些善意的Web標準推廣者還是有錯的，包括我在內，我2004年撰寫的《重構之美》程式碼範例部分帶有更大的誤導性（好在當初我一再強調代碼毫無借鑒的意義，也算在文字上有所彌補）。現在呢？我也不知道，在路上，在路上……

　　寫很多了，span的合理運用留給Update吧。