頁面重構「鑫三無準則」 之「無寬度」準則

1、關於「鑫三無準則」

「鑫三無準則」這個概念早在去年我寫「關於Google圓角高光高寬自適應按鈕及其拓展」一文時就已經提到了。這是本身在頁面重構的經驗中總結出來的一套約束本身CSS的準則，即「無寬度」、「無圖片」和「無浮動」，目的是使CSS佈局模塊化以及加強可擴展性。

此準則是針對我我的的，可能沒有什麼適用性，也可能會對您的學習有所啓發，因此這裏仍是簡單分享下。共三個準則，每一個準則內容都較多，本文就只簡單講講「無寬度準則」。

2、爲何要「無寬度」

先說點題外話。我我的很是不喜歡「切圖」一詞，每次項目經理叫我：「XX，麻煩把這張圖切一下」的時候，內心老是有點不順暢快。「切圖」一詞有將設計 圖切割拼接之意，咱們或許都經歷過這類「切圖」的階段，這是個缺乏創造，缺乏藝術，缺乏技術含量的階段，這是個猶如搭積木般只須要幼兒園智商就能完工的階 段。

一提到「切圖」一詞，我腦中閃現的就是：分割圖片，量體裁衣，計算寬度，頁面元素無縫拼接，而後造成頁面。我剛接觸CSS那會兒就是這麼作的，如今回首看看，當時的那種「切圖」的作法真是差勁得連拜月教主都不如。

具體描述當時的作法，就是精確測量、計算每一個元素的寬度，計算的時候還考慮到margin，padding以及border，老是精確到像素級，然 後使用浮動進行無縫拼接，哇咔咔，當時的我仍是很沾沾自喜的，由於頁面上的寬度啊什麼的都是精確到每一像素，每塊元素都進行準確的計算，是多麼的認真、工 做多麼的努力啊！
如今看來，當時的那些「認真」、「努力」什麼的都是浮雲，徹底就是公公背兒媳婦過河——吃力不討好！

當時的那種作法就稱之爲「切圖」，是很初級和急需提升的階段。爲何說這種「切圖」式的作法很低級呢？一是開發效率低下（要計算寬度什麼的）；二是結構的重用性和可擴展性就是個高郵鹹鴨蛋；三是頁面的往後可維護性就是坨熊貓便便（錯位等bug像要債的同樣三天兩頭串門）。

打個形象的比方，這類寬度計算元素拼接的作法就比如用堅固的磚頭砌房子，一塊一塊的摞起來。最後的頁面看似緊密堅固，可是一旦地震一來，「房子」會 以迅雷不及掩耳的速度垮掉，而那些橫版的木製房卻總能在強震中倖存下來。你有沒有注意到，每當颱風來的時候，最早倒掉的都是平時那些看似堅固的電線杆，但 是卻從未據說過柳樹被風吹倒的。

使用寬度計算+橫向拼接的作法不只浪費精力、開發成本，最終實現的頁面其實也是比較脆弱的。舉個實際點的例子，好比新浪微博內容列表佈局，見下圖：

我用firebug看了下其佈局的方式，結果就是定寬的浮動佈局。左邊頭像左浮動，寬度56像素；右側內容484像素，右浮動。以下圖所示：

這是個比較簡單的兩欄佈局，我估計很多同行會認爲，這裏就應該寬度限定，左右浮動，這也是目前主流佈局方式。可是主流的方法並不必定是最好的方法， 就此例子而言，沒有左右padding/margin/border等屬性，因此右側欄的寬度(484px)肯定貌似仍是比較簡單的（事實上仍是要去量一 下，這是可避免的勞力成本）；可是，其擴展性和重用性則徹底不及格了，首先，這裏的列表不可能放在500像素寬的div中（沒有了重用性），往後要是網站 改版，整體寬度增長，那麼顯然，這裏的寬度又要從新計算，這就缺乏了擴展性；同時，這種浮動佈局會帶來一些反作用，首先是浮動自己的代碼成本，其次是清除 浮動所須要的成本（見下圖）。 //zxx:這裏的width:100%讓IE6/7下li元素haslayout，可修復浮動塌陷的問題，可是我的是不推薦這種作法，要是往後此標籤須要增長左右的margin/padding值，那就有活幹了。

因此，若是以CSS模塊化以及重用性爲基本要求的話，這裏的佈局顯然要「無寬度」，最大限度的利用標籤自己的特性，這樣，CSS代碼成本又小，又利於往後的擴展與維護，何樂而不爲呢？
我本身歸結的這個「無寬度」準則並非本身隨便YY臆想出來的，是時刻以「模塊化和重用性」做爲頁面佈局基本要求下的必然產物。固定的寬度值限制了頁面內容的重用性和擴展性，因此，要想頁面佈局具備較高的重用性和擴展性，咱們須要遵循「無寬度」準則。

咱們到底是在「頁面切圖」仍是在「頁面重構」，或許就體如今一些小的細節與實現方式上。

3、「無寬度」準則之實踐

「無寬度」準則是否真的有其價值所在，看完下面這個例子或許你就有答案了。仍是上面一條徐若瑄的微博爲例子：
首先，您能夠狠狠地點擊這裏：「無寬度」準則對比demo

您會看到相似下面的效果圖：

雖然上下兩個微博列表顯示的是同樣的，可是其佈局方法確實不同的，一個有寬度，一個無寬度。那本文屢次提到的「無寬度」準則又好在哪裏呢？咱們能夠作個小小的test，就能夠看到差異和變化了，就是修改列表外框的寬度，例如，改爲500像素，見下圖，而後點擊肯定按鈕：

結果就會以下圖所示：

能夠看到，定寬佈局的這個精確的寬度值限制了佈局的適應性，換句話說就是定寬佈局限制了內容的模塊化與往後的重用性，擴展性，容錯性也下降了，這也是我爲何很早就提出「無寬度」準則。

4、「無寬度」之實現

這裏我想明確一點，「無寬度」具體指的是沒有固定的寬度值（尤爲是以px爲單位的寬度值，em需看具體狀況，%百分值不在其中）。使用「無寬度」實現各種佈局的內容不少，爲了避免偏離主題，我「就事論事」，只單純講下上面徐若瑄微博的「無寬度」實現。

這是比較簡單的也是比較基本的兩欄佈局，通常這種layout咱們須要藉助一些平時會給咱們帶來麻煩的，自己帶刺的一些CSS屬性，那就是float以及position:absolute屬性，我在「absolute絕對定位的非絕對定位用法」 一文中就屢次提到個人這個觀點：未設定left/top值的absolute元素和float元素就是兩個混蛋近親，一樣的都是「包裹與破壞」，可是，雖 然不少時候，這種破壞會給咱們帶來些麻煩（例如清除浮動形成的高度塌陷的問題），可是，萬物皆有兩面性，咱們有時候能夠利用這種破壞的特性來幫助咱們進行 更加有韌性的佈局。

因爲讓左邊的頭像浮動(float:left)在IE6下會有神奇的3像素bug，因此，我我的偏好於使用position:absolute屬 性，只要這一個屬性就能夠了，而後，右邊的內容就能夠當這個頭像不存在進行佈局，咱們用firebug一看CSS與HTML代碼或許就知道怎麼回事了：

相比原來的代碼，我只是把頭像的56像素寬度左浮動和484像素內容寬度右浮動改爲position:absolute和padding-left:76px，而後，實現的效果就是如出一轍了，不只代碼量少了，佈局也更有擴展性。同時，也不須要什麼清除浮動之類的代碼了：

整個佈局的CSS代碼就很是之清爽，沒有浮動，沒有計算，也沒有清除浮動，並且擴展性強。

.abs{position:absolute;}
.pl76{padding-left:76px;}

以前有很多同行質疑個人CSS架構、命名等相關內容，我是能夠理解的，畢竟不少人成長到必定階段後，會陷入了本身構建的看似金玉的圍牆中，不免會用牆內的眼光看待牆外的世界。上面的佈局，要是在個人CSS架構下，都是直接從庫（通用庫和網站庫）中提出來的，寫頁面根本就不要動CSS文件，因此，我天天都很足夠的時間來寫文章，關注國外最新的前端發展。

固然，實際上的無寬度佈局仍是有不少細節須要注意，就absolute定位而言，就有不少內容，這仍是靠您本身去琢磨了，我這裏就不細細講述了。

所謂「英雄所見略同」，absolute無寬度的定位方法也是Google最大的競爭對手facebook在我的主頁動態列表使用的定位方法：

可是，facebook這裏的absolute定位屬於標籤內定位，外套relative屬性限制，好處在於能夠直接忽略我上面提到的很多須要注意 的細節，且易於理解掌握，可是不足在於CSS代碼量，開銷，開發成本都比較大。因此，我的權衡來說，仍是直接的外標籤裸absolute屬性方法更好些。

還有，今天我去看facebook首頁好友動態列表的代碼，nnd，發現了一個很牛逼的方法，float外加table-cell方法 （table-cell的寬度上千上萬卻依然佈局良好，很神奇），我琢磨着，多是由於國外基本上不鳥IE6瀏覽器的緣故，因此會果敢的使用 display:table-cell屬性，此方法要想在國內盛行，還需有段時日。

此自適應佈局方法方法我頭一次見到，有時間得好好研究研究。

若是你不介意hack，或是你不鳥IE6，本文微博列表的position:absolute直接換成float:left也是能夠的。

5、一點延伸式的結語

我以爲應準確理解本文提到的「無寬度」準則，這個準則是模塊化與重用性高要求下的產物，由於固定的寬度值是限制模塊重用性的最主要緣由之一，因此，才提出了「無寬度」準則。

於是，咱們不要去咬文嚼字，說「無寬度元素」就是指沒有width屬性，而是要思量，這個佈局的寬度值是否影響了此佈局往後的重用性與擴展性。若是 這個寬度不會影響佈局的重用性，例如本例的徐若瑄的頭像寬度，這是個統一的固定的寬度，不影響咱們實現佈局的自適應，就不在「無寬度」準則的範疇內。

本文展現的「無寬度」佈局方法實際上是比較基本的一個佈局方法，web頁面的狀況千差萬別，還有不少其餘的「無寬度」技巧，這就須要您在往後的開發中本身摸索了。

最後，很重要的，若是您重構頁面更關注的是眼下效果的實現，對於一些往後潛在的改動不在乎的話，那您大可沒必要把本文的內容放在心上，就當是隔壁王二奶奶的嘮叨吧。
還有，本文又一次拿新浪微博的佈局/代碼舉例，絕沒有對任何鄙視不敬的意思，主要是由於我基本上只玩新浪微博，拿來作示例比較方便。其實，代碼這東西，好 壞之分不是隻看表面那點東西了，團隊啊，規範啊，傳承啊，不少的因素，新浪微博是個優秀的產品，裏面的前端代碼也是值得學習的。

好吧，就說這些，畢竟資質有限，不免有敘述不許確的地方，歡迎指正，也歡迎交流。