特意上網搜索了一下，關于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吧。