談CSS的設計模式

2024-04-27 15:09:47

字體：大中小

來源：轉載

供稿：網友

拆　　在分了之后，我們的代碼看起來已經比之前好很多了，組織清晰，維護性大幅提高，但是，好像還是不夠，我們會發現另外一些東西，很細小，但復用度也很高，它們同樣不適合被放到模塊中去，比如，邊框、背景、圖標、字體、邊距、布局方式等等。如果我們在每個需要它們的地方，都定義一次，它們會被重復很多次，顯然，這背離好的實踐，會造成代碼冗余和維護困難。所以，我們需要"拆".拆過之后會怎樣？我們想在哪里用可以直接加，需要改的時候統一改。　　排　　經過了"分"、"拆",我們的代碼結構已經十分清晰，各個內容模塊，功能模塊，UI模塊都乖巧的等待召喚，那么還差什么？是的，還差有序的組織，分類清晰之后，還需要排列有序，從不同緯度去考量，我們總能精益求精。舉個栗子，我們可能會看到像這樣：復制代碼@import "mod_reset.CSS";@import "ico_sPRite.css";@import "mod_btns.css";@import "header.css";@import "mod_tab.css";@import "footer.css";復制代碼　　我們將不同的部分按照一定的順序去擺放，能讓我們的代碼看起來更加有序，易于維護，同時，有利于進行繼承或層疊覆蓋。不要小看這一步，看似可有可無，實際要求比較高的統籌規劃能力，可以減少冗余代碼和快速定位問題位置等?！　〕酥猓覀円廊豢梢杂衅渌姆椒▉韼椭覀冞M行區分代碼范圍，比如：　　1、在文件頭部建立一個簡要的目錄　　2、使用區塊注釋　　在注釋中，應該盡量詳細的寫清楚該段代碼的目的，狀態切換，調整原因，交互邏輯等等，這樣不僅利于自己的維護，更加利于別人接手維護你的代碼?！　慕Y論出發　　除了需求當中一些通用部分，另外一些也是需要注意，但不會被正式定義的東西，它們來源于我們的實踐經驗，比如：　　層級嵌套不要太深　　稍微了解一些瀏覽器渲染原理的都知道，它在解析CSS規則的時候，是從右向左，一層層的去遍歷尋找，如果層級太多，必然增加了渲染時間，影響渲染速度。另外，如果選擇器層級過多，也就間接反應了，你的HTML結構可能寫得不夠簡潔?！　∧敲淳唧w多少層合適？一般建議是不超過4層，但話又說回來，超過4層會怎樣嗎？不會有多明顯的影響，除非你寫到很恐怖的數量，或者項目極其龐雜，可能能看出來影響，其實從我們日常需求來看，4層以內足可以解決絕大多數問題，故而，是合理的?！　”苊馐褂迷剡x擇器　　出于兩點考慮：　　第一點，和上一段提到的相關，在HTML中，有很多常用的高頻元素，比如，div、p、span、a、ul等。如果，你在多層選擇器的最內層使用了元素選擇器，那么，在開始尋找時，瀏覽器就會遍歷HTML中的所有該元素，顯然，這是沒有必要的?！　〉诙c，我們的需求和代碼結構都是存在著潛在變化的，今天寫好了一個頁面，明天可能就要再加進去一個按鈕，再加進去一句話，再加進去一個圖標。我們寫好的一個結構，也隨時可能被復用到別的結構中去。所以，如果，你使用了元素選擇器去定死某個東西，不論是新加進來的東西，還是被復用的東西加到別的結構里去，都極有可能產生樣式的沖突，這個時候，你又不得不寫多余的樣式進行覆蓋修正，或者重新定義類。

　　所以，出于以上考慮，在具體的代碼模塊中，盡量不要使用元素選擇器，使用元素選擇器的前提是，你完全的確定，不會導致出現問題。注意，我用的限定范圍是"具體的代碼模塊",那么用于定義通用規則的樣式，是可以的，也是推薦使用的，比如，reset.也可以是別的地方，這就需要我們自行考量。

<div class="bottom_soft_link">　　<a target="_blank" class="bottom_soft_link_ios" href="xxx.com" title="客戶端蘋果手機APP下載">iOS下載</a>　　<a target="_blank" href="http://linyi.changtu.com/" title="臨沂汽車總站時刻表">臨沂汽車總站時刻表</a>　　</div>

上一篇：web前端研發工程師編程能力成長之路 [轉]

下一篇：如何使用DevTools調試Nodejs運行的Javascript